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

[Christian Brauner]

On Mon, Oct 19, 2026 at 07:01:14AM -0500, Serge Hallyn wrote:
> 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?

I want as little moving parts as possible. :)

> 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),

So that's pretty common though. Doesn't Incus do exactly that? And it
does write fscaps through onto the host on purpose and restricts access
to /var/lib/containers via strict DAC.

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