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