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 %%