[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
- Re: libcap vs libcap-ng mess,
Dr. David Alan Gilbert <=