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