Subject: Re: [vserver] grsec change propositions
From: Ed W <lists@wildgooses.com>
Date: Fri, 18 Jun 2010 11:17:01 +0100

Hi

> 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?)
>    

Based on a position of ignorance I have been running your merged kernel 
sources for the last few years with something like the following options:

[*] Chroot jail restrictions
[ ]   Deny mounts
[ ]   Deny double-chroots
[*]   Deny pivot_root in chroot
[*]   Enforce chdir("/") on all chroots
[ ]   Deny (f)chmod +s
[*]   Deny fchdir out of chroot
[*]   Deny mknod
[*]   Deny shmat() out of chroot
[*]   Deny access to abstract AF_UNIX sockets out of chroot
[*]   Protect outside processes
[ ]   Restrict priority changes
[*]   Deny sysctl writes
[ ]   Capability restrictions

So, unless you tell me that some of these options are already irrelevant 
because of the vserver patches then it seems like it's useful to leave 
them available?

Disabling the 4 relevant options when using vserver seems extremely 
sensible though (option 2) and would appear to be a fairly 
straightforward change and the minimum we should do?

I guess I would like to hear more reasons why option 3) is actually 
useful?  Seems on the surface to cause few problems and only reduce 
security/choice?

However, I concede huge ignorance on the effects of these options...

Thanks for continuing to maintain this!

Ed W