qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libcap vs libcap-ng mess


From: Dr. David Alan Gilbert
Subject: Re: libcap vs libcap-ng mess
Date: Mon, 2 Dec 2019 10:07:31 +0000
User-agent: Mutt/1.12.1 (2019-06-15)

* Paolo Bonzini (address@hidden) wrote:
> Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <address@hidden> ha
> scritto:
> 
> > > Yes, it's per thread.  The state can be built from
> > > capng_clear/capng_get_caps_process + capng_update, and left in there
> > > forever.  There is also capng_save_state/capng_restore_state which, as
> > > far as I can see from the sources, can be used across threads.
> >
> > So, I think what you're saying is I need to:
> >   a) Before we sandbox do the capng_get_caps_process
> >
> 
> Why not after sandboxing?

Because in our sandbox we don't have /proc and capng_get_caps_process
tries to read /proc/.../status and fails. The old libcap code doesn't
use /proc, it just uses capget (which the new one also uses).

> If the code is in any way similar to the 9p
> proxy, you have two states, "sandboxed with capabilities" and "sandboxed
> without capabilities". The former (permitted=effective) is what you get
> after setresuid/setresgid, the other can be computed after sandboxing and
> saved using capng_save_state. The FSETID capability can be updated
> explicitly before/after capng_apply.
> 
>   b) Before we start a new thread do a capng_save_state and restore it
> > in the thread
> >
> 
> Or just save after (a), and restore always before capng_apply.

Hmm yes, that's easier.

>   a) This code is very local - it does a drop FSETID, a write, restore
> > FSETID
> >   b) I'm not sure but I suspect it's used only in the non-uid=0 case;
> > the whole thing is just a hack to cause setuid/setgid to be dropped
> > in the case where it's written by a process that doesn't have FSETID
> > (hmm I guess if the guest was root but didn't have fsetid then it would
> > be 0?)
> >
> 
> Yes it would. For uid!=0 the kernel clears the effective capabilities so it
> shouldn't need to do anything, unless virtiodsd restores capabilities after
> setresuid/setresgid.
> 
> But are you suggesting I need to change something other than the
> > effective caps in that case?
> >
> 
> No, only the effective caps.

OK, thanks.

Dave

> Paolo
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK




reply via email to

[Prev in Thread] Current Thread [Next in Thread]