RE: [vserver] Capabilities in Vserver Kernels

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