Mniej wiecej Mon, Feb 18, 2008 at 09:20:28AM +0100, zainteresowany Natanael Copa rzekl:
>
> On Fri, 2008-02-15 at 17:04 +0100, Zbyniu Krzystolik wrote:
> > Mniej wiecej Thu, Feb 14, 2008 at 10:10:10AM +0100, zainteresowany Natanael Copa rzekl:
> > > Hi,
> > >
> > > I have been thinking lately of the grsecury patch. There are many
> > > features in grsecurity that is redundant or does not really work very
> > > well with vserver.
> >
> > What features don't work?
> ...
> >
> > First problem here is to manage such policy, it is not pretty readable.
>
> But you cannot manage policies within each vserver.
Yes, like you cannot manage network. IMO it is difficult to create
without productivity/security consequences.
> > Other thing is vhashify - if you use it RBAC will refuse policy because
> > of hard links. For existing files grsec uses inodes, there will be
> > posibility to create duplicates in policy what is prohibited.
> >
> > > grsecurity also provides some features to prevent escaping from a
> > > chroot. A vserver is a chroot and has its own mechanism to prevent
> > > escaping. So I think the additiona features provided in grsecurity
> > > should be added to vserver if they are needed.
> >
> > But where is the problem? Two projects provides independent
> > implementations of similar functionality. If used together must be
> > configured with caution. That's all.
>
> problem is that increased complexity means increased risk something goes
> wrong during the merge. It also means a minor additional delay for
> updates. (keep things simple etc...)
No risk, no fun ;)
Delays are caused chaos generated by mainline kernel big changes.
> its not a problem. more a suggestion to make maintainership easier.
But have you ideas what practical hooks can be made between grsec and
vserver?
> > There is not problem to create vserver+pax.
>
> Did you try it?
Yes, but I use vserver+grsec.
> Does it have many conflicts?
No, just few and simple changes.
Zbyniu
-- %% Absolutely nothing we trust %%Received on Tue Feb 26 22:03:09 2008