Subject: Vserver + grsec thoughts
From: Ed W <lists@wildgooses.com>
Date: Wed, 03 Nov 2010 17:48:05 +0000

Hi, there is a bunch of commentary about the grsec/pax patch recently, I 
asked around a little and just wanted to summarise some notes:

- The most interesting part of the grsec patch seems to be the "PAX" 
part.  This is mainly about making data pages non executable, but the 
patch size appears dominated by changes to "constifying" various parts 
of the kernel and catching dereference errors.

- The PAX patch appears to apply cleanly against linux-vserver patches 
(Rik could you perhaps comment if there are hidden gotchas though?)

- Apart from an RBAC system (which doesn't completely integrate with VS) 
the GRSEC patches mainly enhance logging, restrict /proc visibility and 
lock down chroot escapes - the later seems to be the main attractive 
item.  However, discussing those restrictions with Herbert he suggests 
that possibly those restrictions are amply protected in VS already?  
Herberts comments below - I would appreciate thoughts from the audience:


>> >  CONFIG_GRKERNSEC_CHROOT_PIVOT=y
> 	sys_pivot_root() requires CAP_SYS_ADMIN
>
>> >  CONFIG_GRKERNSEC_CHROOT_CHDIR=y
>> >  CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
> 	this is blocked (for the guest root) with
> 	barrier and pivot_root (with recent utils)
>
>> >  CONFIG_GRKERNSEC_CHROOT_MKNOD=y
> 	sys_mknod() requires CAP_MKNOD
>
>> >  CONFIG_GRKERNSEC_CHROOT_SHMAT=y
> 	a guest can only attach to shared memory
> 	inside the guest
>
>> >  CONFIG_GRKERNSEC_CHROOT_UNIX=y
> 	same for abstract unix sockets
>
>> >  # CONFIG_GRKERNSEC_CHROOT_NICE is not set
> 	guest have a priority offset and an
> 	upper bound for the priority inside
>
>> >  CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
> 	this requires euid = 0, which is not true
> 	inside any guest
>

So my question is really what the grsec patches add for the situation 
that the host is considered "secure" and we are interested only in 
locking down the guests.  Assuming Herbert has understood the grsec 
chroot changes correctly then the interesting grsec additions appear to 
be: larger entropy pools, some better logging of mounts/segfaults, some 
small extra hardenings of /proc and probably some other things I forget 
writing this off the cuff?  The grsec RBAC is complicated to use in a 
guest (does anyone at all use it?)

If so then my thought is to use only the pax patch (and perhaps cherry 
pick some individual bits of grsec).  This would seem to be easier to 
maintain and appears to keep 95% of the benefits?  The pax guys seem to 
be extremely helpful and responsive to problems (just like 
linux-vserver), so it seems useful to be able to keep fairly up to date 
on both patch sets?

Any thoughts?  (I'm especially hoping to hear from Rik?)

(Note: To those wondering why add Pax at all.  For a hardened server 
installation it appears to have successfully mitigated most of the 
recent kernel bugs. If you are also compiling with -fstack-protector and 
PIE then it seems to make a large class of userspace attacks (buffer 
overflows in particular) fairly difficult.)

Cheers

Ed W