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? 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.
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.
Paolo