probably it is not good way to block GRKERNSEC_CHROOT_FINDTASK and GRKERNSEC_CHROOT_DOUBLE cos someone (me) does not use/need/allow chroot in chroot Rik Bobbaers wrote: > Okay, > > in order to make vserver+grsec a bit more "robust", i made some changes to > the current patch: > 1. updated to the latest grsecurity 2.2.0 > 2. by default, the following grsecurity options are made impossible if > VSERVER is enabled in the kernel: > GRKERNSEC_CHROOT_MOUNT > GRKERNSEC_CHROOT_DOUBLE > GRKERNSEC_CHROOT_CHMOD > GRKERNSEC_CHROOT_FINDTASK (vserver works with it, but when you have a > chroot inside a vserver, you can't see the tasks running in there) > GRKERNSEC_CHROOT_CAPS > > I hope it all works as expected. In case of problems, just let me know!!! > > Greetings, > > Rik Bobbaers > > -- http://harry.enzoverder.be > linux/unix/system/network/security/hardware admin > infrastructure architect > >> Heya all, >> >> As Bertl isn't a real fan of the vserver+grsec merge since it's easy to >> run into problems when you don't properly configure stuff. >> >> SO, a proposition: >> vserver is largely based on chroot and lots of options related to that. >> The grsecurity part has a famous "chroot restrictions" list. Some options >> need to be disabled to make vservers work properly. Right now, leave the >> choice to the user to config it, but it causes problems when you "just >> enable all" >> >> 3 possibilities: >> 1. disable ALL chroot restrictions when vserver kernel is enabled >> 2. disable the 4 restrictions and leave the choice for the rest of the >> chroot restrictions >> 3. SCREW IT, I'm a grown boy, i decide what i want, this is a free country >> (wether or not you live in one ;)) >> >> anyway, I personally would disable all chroot restrictions, since security >> on the guests is primarily enforced by vserver code itself. The second >> option has more options for the user (do you want that?) >> The third option is maybe not optimal since noobs will run into problems. >> >> Are there more requests on "better integration" of grsecurity and >> linux-vserver? >> >> ps. i'm not an expert in the linux-vserver code nor the grsecurity/pax >> code, so don't ask me to completely rewrite any of the 2! ;) >> >> Bertl: you're the leader of the linux-vserver, so your suggestions weigh >> more in discussions! I want you to "enjoy" having a vserver+grsecurity >> patch instead of resenting it. >> >> anyway: let the discussions run wild!!! ;) >> >> Rik Bobbaers >> >> -- http://harry.enzoverder.be >> linux/unix/system/network/security/hardware admin >> infrastructure architect >> >> >> >