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
Received on Thu Nov 4 08:41:26 2010