Suggestion for kernel tree: Pax + linux-vserver
 

Just to run an idea up the flagpole...

I have had good success with a slightly orthogonal approach to securing
my servers. I run a hardened gentoo install, but with linux-vservers
for the guests and additionally pax kernel patches.


The motivation is that Pax has mitigated a reasonable proportion of
recent kernel issues. On the userspace side, linux-vservers are
something like chroot-on-steroids and make it very straightforward to
ringfence user applications without quite going to a full virtualisation
solution. (For those who don't know, Linux-vservers look and smell like
a virtualisation solution, but they are implemented using a kind of
chroot - lxc containers are re-implementing the same idea, but currently
much less advanced)


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


So the proposal is to recognise another secure setup which is:

- Minimal host installation + linux-vserver / pax kernel
- Applications moved to lightweight vserver guests (go pretty much one
application / webapp per guest)


Who cares?

Cheers

Ed W

Suggestion for kernel tree: Pax + linux-vserver
 

2010/11/3 Ed W <lists@wildgooses.com>

Just to run an idea up the flagpole...



I have had good success with a slightly orthogonal approach to securing my servers. �I run a hardened gentoo install, but with linux-vservers for the guests and additionally pax kernel patches.



The motivation is that Pax has mitigated a reasonable proportion of recent kernel issues. �On the userspace side, linux-vservers are something like chroot-on-steroids and make it very straightforward to ringfence user applications without quite going to a full virtualisation solution. (For those who don't know, Linux-vservers look and smell like a virtualisation solution, but they are implemented using a kind of chroot - lxc containers are re-implementing the same idea, but currently much less advanced)




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




So the proposal is to recognise another secure setup which is:



- Minimal host installation + linux-vserver / pax kernel

- Applications moved to lightweight vserver guests (go pretty much one application / webapp per guest)



Who cares?



Cheers



Ed W



I do care- Francesco Riosa

Suggestion for kernel tree: Pax + linux-vserver
 

El 04/11/10 00:26, Francesco R escribió:

2010/11/3 Ed W <lists@wildgooses.com>


Just to run an idea up the flagpole...



I have had good success with a slightly orthogonal approach to
securing my servers. *I run a hardened gentoo install, but
with linux-vservers for the guests and additionally pax kernel
patches.



The motivation is that Pax has mitigated a reasonable
proportion of recent kernel issues. *On the userspace side,
linux-vservers are something like chroot-on-steroids and make
it very straightforward to ringfence user applications without
quite going to a full virtualisation solution. (For those who
don't know, Linux-vservers look and smell like a
virtualisation solution, but they are implemented using a kind
of chroot - lxc containers are re-implementing the same idea,
but currently much less advanced)



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



So the proposal is to recognise another secure setup which is:



- Minimal host installation + linux-vserver / pax kernel

- Applications moved to lightweight vserver guests (go pretty
much one application / webapp per guest)



Who cares?



Cheers




Ed W






I do care
- Francesco Riosa

Hello Ed,



I was speaking on the matter with blueness and he said he won't mind
proxying you if you take care of a new ebuild (I suggested
hardened-vserver-sources for example) and the docs. On my side I can
help you a bit with the docs, specially with formatting and exposing
things in a newbie understandable way, though as I don't know about
vserver I won't be able to write those docs, sorry.



Take care

klondike

Suggestion for kernel tree: Pax + linux-vserver
 

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 ? ;)

Suggestion for kernel tree: Pax + linux-vserver
 

On 04/11/2010 21:56, pageexec@freemail.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

Suggestion for kernel tree: Pax + linux-vserver
 

On 04/11/2010 02:45, klondike wrote:
I was speaking on the matter with blueness and he said he won't mind
proxying you if you take care of a new ebuild (I suggested
hardened-vserver-sources for example) and the docs. On my side I can
help you a bit with the docs, specially with formatting and exposing
things in a newbie understandable way, though as I don't know about
vserver I won't be able to write those docs, sorry.


OK, well I'm still working through the issue of whether to use only
pax+vserver, or to try and integrate the full grsec patch (much more
maintenance). I will come back with something after that


Thanks for the interest

Ed W