Re: [gentoo-hardened] Suggestion for kernel tree: Pax + linux-vserver

[Ed W]

On 04/11/2010 21:56, pageexec@××××××××.hu wrote:
> On 3 Nov 2010 at 18:24, Ed W wrote:
>
>> Up until now I have also been running kernels with the grsec patches,
>> but merging those with linux-vserver is relatively complex since there
>> is some overlap.  Additionally it would appear that linux-vservers offer
>> a large chunk of the protection that the grsec restrictions should
>> offer.  You loose the grsec RBAC system by going only PAX, but that
>> doesn't quite work as expected with vservers, so I would think most
>> users wouldn't implement that anyway
> how about http://linux-vserver.org/Welcome_to_Linux-VServer.org ? ;)
>

Sorry to be dim, but I don't get it?  That's just the front page of the 
vserver project?

Is your point that the grsec+vserver patches are quite out of date?  If 
so then yes I agree - that's really how this conversation has come 
about.  At the moment they are produced by "Harry" who has decreased 
time to work on them.  The suggestion is to perhaps to use only 
vserver+pax, which should be much easier (and timely) to merge?

Oh, also that first sentence should actually ready "I have been running 
with vserver + grsec patches" - was that your point?

The pax changes are largely independent of the vserver code.  The grsec 
stuff has significant and subtle overlaps with the vserver stuff (which 
is basically a bunch of somewhat hardened chroots), and merging is non 
trivial.  I think that whilst grsec is a great set of hardenings, there 
is a case that the cost of maintaining the merged patch could be argued 
to outweight the benefits?  For example I would invite your opinion, but 
it would appear that most of the chroot protections in grsec are covered 
by the vserver patch (obviously only with regards to breaking out of the 
vserver, not other chroots).  There are some other bits of grsec that 
would be desirable to keep, eg the increased entropy pool, kernel 
logging and perhaps the /proc restrictions, but I'm hoping these will be 
easy to pull out and add on to a pax+vserver base?

How likely is it that the grsec team would maintain a reduced patch 
without the chroot bits and the other stuff that is hard to merge with 
vserver?  Actually - how likely that the grsec team would enhance the 
RBAC to work inside a chroot such a lxc/vservers?



Anyway, the above is the reasoning behind going (at least initially) 
with pax rather than full grsec.  However, the more important part of 
the proposal was really the use of vservers (ie fancy chroots) to split 
a monolithic server up into basically a setup where you pretty much 
chroot every service into it's own vserver.  It can be argued this can 
be done already using other tools, but lets just call vservers a fancy 
chroot with wrappers to more easily maintain a more "full on chroot" 
which looks 3/4 of the way to a virtualisation product.

I'm not sure if it needs justifying further, but I find that a "fat 
chroot" such as vserver makes it easier to maintain because you can use 
your normal package tools to maintain the software.  Arguably you can 
get lighter still with custom chroots, but I find the overheads pretty 
negligible for my setup and the maintenance is very straightforward 
(especially if you introduce some custom profiles)

Basically the security comes from splitting up the services into their 
own containers (compromise of one shouldn't affect the others) rather 
than trying to harden a single machine to be unbreakable.  It's 
particularly interesting for web apps where coding errors are common and 
easy to remotely exploit...


I realise that you are part of the pax team so I'm a bit unsure what 
your question really was?  Hopefully the above hits several of the 
things I think you might have meant?



Cheers

Ed W