On Thu, Oct 29, 2026 at 5:11 AM Hallgrimur H. Gunnarsson
[off-list ref] wrote:
On Wed, Oct 28, 2026 at 03:56:11PM -0700, Andy Lutomirski wrote:
quoted
Why should the task's cap masks affect this? *Maybe* cap_bset makes
sense, but I'm struggling a bit to see why cap_permitted and
cap_effective should matter.
Sorry, the phrasing here may have been misleading. Just to clarify:
none of the creating task's capability sets (cap_bset, cap_permitted
or cap_effective) are used to restrict the new user namespace.
When I wrote "reusing the existing task cap_bset, cap_permitted and
cap_effective sets on namespace entry", I was contrasting this with
the prior series from 2024 [1], which proposed adding a 6th per-thread
capability set to struct cred.
In this series, when a task creates or enters a user namespace, we
simply initialize its new cred->cap_{bset,permitted,effective} in
that namespace to user_ns->cap_bset instead of CAP_FULL_SET.
Okay, this makes *more* sense, but I think it's too weak.
I have a sort-of goal of having the creation of unprivileged
namespaces be allowed in most contexts by default, *even in Docker*
(which would involve the Docker team changing their default seccomp
rules, but that bridge can be crossed later). (In furtherance of this
goal, I fixed an ancient bug in newuidmap that gets us quite a bit
closer a couple weeks ago.)
But tying this mitigation to a parent userns means that it's
completely unusable in the single-deep case.
I do have a question about this whole scheme, though: are we talking
*just* about CAP_NET_ADMIN? That is, is there any other bit that has
anywhere near enough security relevance to make this kind of thing
worthwhile? Because if it's really just a single bit control, maybe
we can come up with a nicer scheme.
--
Andy Lutomirski
AMA Capital Management, LLC