Subject: Re: [vserver] Vserver + grsec thoughts
From: "Rik Bobbaers" <rik@enzoverder.be>
Date: Thu, 4 Nov 2010 09:41:09 +0100 (CET)


Rik Bobbaers

-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect

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

first of all: You are absolutely right!

except on 1 thing: pax integrates nicely, but iirc (don't have the
time/tools here to check) the refcounter issues are in pax, but that's
just a small not very invasive patch and fairly constant across the
versions.

There isn't all that much to do when you leave out the grsecurity part of
the patch. I already suggested in the past to drop that. But there were
(at that moment) people who didn't want to give up on the grsecurity
things.

chroot restrictions:
Personally i don't use the chroot restrictions, because as Herbert says:
vserver makes chroot more secure and better. But some time ago, I asked if
everyone was OK if i remove the option (grkernsec_chroot) completely in
the patch, and there were people that didn't want that, because their
point of view (at that moment) was: if you don't want it, don't use it. If
you want it, you can still play with it.
It's only recently that Herbert asked/insisted to integrate grsecurity
"better" with linux-vserver, that i removed some chroot options
"hardcoded" in the kernel that are known to "break" vserver.

But as i don't have the time nor possibilities to work on the patches (I
work in a bank now, so it's a windows system and everything is properly
locked down... well... not really, but when i bypass security, the ids
alarms start to ring etc etc... :)). It might be a good idea to switch to
"linux-vserver + pax" patches.

Or, maybe if someone says: no waaaaay... he can take over? ;)
It's not all that hard to do, just keep your head to it, and know some C
coding ;)
I don't want to give this work up, but i really don't have the time it
takes to do it properly (sorry)

So yeah... it is an interesting question, but i think it's up to the
community to speak now ;)

Greetings,

Rik
aka harry