On 04/11/2010 21:56, [email protected] 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
