Re: [PATCH 0/5] capabilities: close the ways around the CAP_SETFCAP rule for uid 0

[Serge E. Hallyn]

On Tue, Oct 13, 2026 at 07:32:13PM +0000, Josef Bacik wrote:
> On Fri, Oct 09, 2026 at 09:41:59AM +0200, Christian Brauner wrote:
> > On Thu, Oct 08, 2026 at 11:13:57AM -0500, Serge Hallyn wrote:
> > > Yeah, that's what I was thinking.  Or even stricter: ensure that to join
> > > any user namespace, a process must have a superset of the namespace
> > > creator's capabilities.
> >
> > I think both are fine and I like this proposal.
> 
> One correction to what I wrote: the weaker version isn't enough.  A
> namespace that maps "0 100000 1000" doesn't map the parent's uid 0, so
> it passes that check.  But with an idmapped mount that maps fs 0 to
> 100000, a task that joined it can write fscaps that are stored with

I actually don't think that's something we should work around here.

Christian, what is your opinion on this?

IMO most people should not do id-mapped mounts from host range anyway
(they should shift a base rootfs to a high range, then do idmapped
mounts from there),

> rootid 0 and honoured by the host.  We test that flow.  So it has to be
> Serge's stricter version.
> 
> > I think that this is an acceptable restriction. Mapping uid 0 to 0 and
> > dropping caps is borderline useless.
> 
> That makes the restriction wider than the 0 to 0 case.  A root task
> without CAP_SETFCAP couldn't join an ordinary "0 100000" container
> either.
> 
> setns() also only covers the routes that go through it.  These don't,
> and need their own checks either way:
> 
> - writing through a uid_map fd opened by a task with CAP_SETFCAP
> - ptrace and pidfd_getfd of an entitled task from outside
> - a task without CAP_SETFCAP creating its own namespace, which a
>   privileged task then maps "0 0 1" for
> 
> So v2 would be a level on the namespace computed at create time, the
> strict setns() check, and the checks at the map write, setxattr and
> ptrace reading the namespace's level instead of the cred's.  If that
> sounds right I'll put it together.

I still think it would be easier to reason about, long term, if we
could get away with storing the cap_eff of the process which creates
the user namespace, and check (ns-targeted) the capabilities of any task
trying to setns to it against that.

> Thanks,
> Josef