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
>>
>>
>>
>
Received on Mon Jun 21 14:48:56 2010