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.
> 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...)
its not a problem. more a suggestion to make maintainership easier.
...
> There is not problem to create vserver+pax.
Did you try it? Does it have many conflicts?
thanks for your comments.
-nc
Received on Mon Feb 18 08:23:58 2008