On Wed, Nov 4, 2026 at 3:30 AM Hallgrimur H. Gunnarsson [off-list ref] wrote:
On Tue, Nov 03, 2026 at 10:37:48AM -0800, Andy Lutomirski wrote:
quoted
On Thu, Oct 29, 2026 at 5:11 AM Hallgrimur H. Gunnarsson
[off-list ref] wrote:
quoted
On Wed, Oct 28, 2026 at 03:56:11PM -0700, Andy Lutomirski wrote:
quoted
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.
To clarify, this mitigation isn't exclusively tied to the parent userns.
If a system administrator wants a host-wide policy, like trimming
CAP_NET_ADMIN for all unprivileged user namespaces, including
single-deep Docker containers, then the host-wide sysctl handles this
seamlessly. Any unprivileged process in init_user_ns calling CLONE_NEWUSER
is subjected to the sysctl ceiling, effectively stripping CAP_NET_ADMIN
upon creation.
Seems reasonable, but see below.
Where the single-deep case falls short in this series is per-container
granularity. For flexible configuration on a per-container basis, this
patch series assumes that containers run in their own user namespace,
allowing the runtime to bound capabilities at creation time via clone3()
and have that bound persist down the namespace hierarchy across any nested
userns creation.
There are plenty of cases of *privileged* user namespaces (i.e.
created by privileged users) that would nonetheless want this. Or
unprivileged user namespaces on systems that will not have this
restriction set that still want to apply it in their own container.
If a container runs in init_user_ns (as in standard Docker) and we want
to restrict userns capabilities for that specific container without
relying on a host-wide sysctl, then you are exactly right. We would need
some kind of cred-based mechanism to pre-configure a restriction for any
future CLONE_NEWUSER calls within that container.
quoted
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.
Yes, primarily CAP_NET_ADMIN, and to a lesser extent CAP_NET_RAW.
If we look at submissions to Google's kernelCTF VRP [1], 90% of the
exploit submissions in 2026 require CAP_NET_ADMIN (and about 70%
across all submissions since the program started in 2023).
Restricting these network capabilities when they are not strictly needed
(e.g. for sandboxing) is the primary motivation behind the series.
However, I wrote the userns capability bounding as a generic mask so it
could restrict arbitrary capabilities down the hierarchy, but if the
preference is to narrow the scope more specifically to trimming
CAP_NET_ADMIN and CAP_NET_RAW, that's completely fine by me.
If we go that route and want to support the single-deep Docker case, a
per-task inheritable securebit might be one way to do it, e.g.
SECBIT_NO_USERNS_NET and SECBIT_NO_USERNS_NET_LOCKED. Docker could then
set and lock that bit on a container in init_user_ns without needing a
parent userns.
This seems perhaps better. But maybe a bit that applies the
restriction to a userns created by someone who doesn't have
CAP_NET_ADMIN in their own userns?
IMO what we really want is a generic mechanism for sysctl-like
settings that are scoped to a userns. And we would want the API not
to be filesystem-based (or at least not require *mounting* a
filesystem) because then we would just make everything messier. This
would solve many problems.
On userns creation, create_user_ns() could record this restriction on
struct user_namespace. That could either feed into the userns capability
bounding set proposed in this series (clearing CAP_NET_ADMIN and
CAP_NET_RAW from user_ns->cap_bset when the bit is set on the creator),
or be stored as a single boolean in struct user_namespace if we want to
keep the mechanism minimal and drop the generic capability mask UAPI.
In the latter case, we would still need to replicate some of the
userns capability bounding functionality, e.g. strip CAP_NET_ADMIN and
CAP_NET_RAW in set_cred_user_ns() on namespace entry, and bound the
parent-owner check in cap_capable_helper().
[1] https://github.com/google/security-research/tree/master/pocs/linux/kernelctf