[vserver] Vserver + grsec thoughts

From: Ed W <lists_at_wildgooses.com>
Date: Wed 03 Nov 2010 - 17:48:05 GMT
Message-ID: <4CD1A055.8050100@wildgooses.com>

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
Received on Wed Nov 3 17:49:23 2010

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 03 Nov 2010 - 17:49:23 GMT by hypermail 2.1.8