On Mon, Jun 10, 2024 at 01:47:13AM -0700, Jonathan Calmels wrote:

On Sun, Jun 09, 2024 at 08:50:24PM GMT, Serge E. Hallyn wrote:

quoted

On Sun, Jun 09, 2024 at 03:43:34AM -0700, Jonathan Calmels wrote:

quoted

Attackers often rely on user namespaces to get elevated (yet confined)
privileges in order to target specific subsystems (e.g. [1]). Distributions

I'd modify this to say "in order to target *bugs* in specific subsystems" :)

Ack

quoted

quoted

This effectively mimics the inheritable set rules and means that, by
default, only root in the user namespace can regain userns capabilities
previously dropped:

Something about this last sentence feels wrong, but I'm not sure what
the best alternative would be.  As is, though, it makes it sound as though
root in the userns can always regain previously dropped capabilities, but
that's not true if dropped in ancestor ns, or if root also dropped the
bits from its bounding set (right?).

Right, the wording is a little bit confusing here I admit.
What I meant to say is that if a cap is dropped in a *given* namespace,
then it can only be regained by root there. But yes, caps can never be
regained from ancestors ns. I'll try to rephrase it.

BTW, this is rather strict, but I think that's what we want right,

Yes,

something simple? Alternative would be to have a new cap masked off by
default, but if granted to a userns, allows you to regain ancestors
caps.

we absolutely do not want to allow regaining caps dropped in an
ancestor namespace.

thanks,
-serge