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
Received on Fri Jun 18 11:17:40 2010