Joe Gooch wrote: > See inline. > > Joseph Gooch > Sapphire Suite Product Manager > K12 Systems, Inc. > (866) 366-9540 > > >> -----Original Message----- >> From: Daniel Hokka Zakrisson [mailto:daniel@hozac.com] >> Sent: Monday, June 16, 2008 4:27 PM >> To: Joe Gooch >> Cc: vserver@list.linux-vserver.org >> Subject: Re: [vserver] Capabilities in Vserver Kernels >> >> Joe Gooch wrote: >> > I have diagnosed what I believe to be an incorrect use of >> capabilities >> > in virtual contexts. I believe the vx_mask_cap_bset function in >> > kernel/vserver/context.c should mask based on vx_bcaps, not >> vx_cap_bset. >> > >> > Rationale: >> > vx_cap_vset is the capabilites set from /proc/sys/kernel/cap-bound, >> > which is global for the system, not by VM. Using vx_bcaps >> allows it >> > to be set by vm. >> >> Uh, no, it's the other way around. vx_bcaps can only be set >> from the host. >> The purpose of vx_cap_bset is to allow the guest to set >> /proc/sys/kernel/cap-bound on its own, independently from the >> host (obviously not to raise it). >> >> (Also, VM is really not the right term. It's not virtual, and >> it's not a machine. :-)) > > VS then. :) > > OK, well if that's the intention, it's still not working. > > Host# cat /proc/sys/kernel/cap-bound > 128 > > (128 equates to CAP_SETUID) > > Host# vserver support exec cat /proc/sys/kernel/cap-bound > 128 > > Host# cat /etc/vservers/support/bcapabilities > ~CAP_SETUID That is perfectly fine. We don't mask vx_bcaps until it's used, which means software like BIND9 works without modifications in a guest, as well as gives you the ability to dynamically change the capabilities assigned to a guest. So that guest won't be able to do anything requiring CAP_SETUID... > In fact, in examining the code, vx_cap_bset is only ever set from the > calling context. It's never pulled from anywhere else, as far as I can > tell. Bcapabilities are dumped directly into vx_bcaps. ... without the patch in my email, yes. > As a side note, I spend a large amount of time searching for the proper > way to use bcapabilities and ncapabilities and such, but could not find an > explanation of what these were or what they were intended to be used for. > It could be part of the wiki restructuring; I'm not sure. So my knowledge > in this regard is based on the code without context. http://linux-vserver.org/Capabilities_and_Flags (which is linked from http://linux-vserver.org/Documentation). > [...] > So now, vserver. I don't have an example of what it does unmodified > (since I'm using this patch in production. And it does work. It makes > the vserver behaviour consistent with the parent kernel), but here's what > it does modified. > > Host /proc/sys/kernel/cap-bound is 128 > Bcapabilities is ~CAP_SYS_BOOT and ~CAP_AUDIT_WRITE (in addition to the > others vserver drops): > > # vserver support exec getpcaps = > Capabilities for `=': = > cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_net_bind_service,cap_sys_chroot,cap_sys_ptrace,cap_sys_tty_config,cap_lease+eip > > My new root process is limited by bcapabilities... > > # execcap ' =eip cap_lease,cap_net_bind_service,cap_setpcap-eip ' vserver > support exec getpcaps = > Capabilities for `=': = > cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_sys_chroot,cap_sys_ptrace,cap_sys_tty_config+eip > > But it's ALSO bounded by inheritable sets. None of these are interesting, as they all show the per-process values. If you'd actually try to use a capability that's not in vx_bcaps, you'd get EPERM, as expected, since you need to have _both_. /proc/<pid>/status shows the masked values, i.e. what's actually used by permission checks. >> > The patch can be found here. >> > >> http://users.k12system.com/mrwizard/software/patch-vserver-cap_bound_s >> > et.diff >> >> The only bug that I see is that we don't let guests modify >> vx_cap_bset at this time, but >> http://people.linux-vserver.org/~dhozac/p/k/delta-cap_bset-fix01.diff >> should take care of that... > > I wouldn't use this. I wouldn't want my guest to change it anyway. The > fix here is the behavior of new processes and where and how they receive > capabilities from the parent. "Parent"? Process? The host? -- Daniel Hokka Zakrisson