Restrict namespaces and capabilities

[nbouchinet-anssi]

I think Landlock could benefit to a proper way to restrict namespace creation.
I do not have a UAPI in mind yet, the issue should be edited later in order to clarify it.

Why restricting the use of namespaces ?

• Restrict the creation of namespaces to a selected subset.

Namespace restriction is sometimes achieved through seccomp filters. However,
because seccomp filters cannot dereference pointers, they cannot be used to
restrict namespace creation via clone3(2). As a result, clone3(2) sometimes
is entirely disabled (e.g., Docker's default seccomp profile that denies
CLONE_NEWUSER).

Landlock could provide a way to restrict thoses without requiring a seccomp
filter that completely denies clone3(2).

Unprivileged user namespaces also greatly increase the Linux kernel attack
surface. Landlock could benefit from a mechanism to deny the creation of
unprivileged user namespaces.

Landlock could provide a way to restrict non-user namespaces creation from an
user namespace to a subset of thoses.

• Restrict depth of nested user namespaces.

Similar to user.max_user_namespaces, but enforced at the thread/process level.

What about capabilities restriction ?

• Restrict the capabilities gained through the creation of a user namespace
  to a defined capability subset.

This would allow control over capabilities obtained through unprivileged user
namespaces prior to namespace creation.
Also ensuring no capabilities can be gained or inherited from within a
user-namespace.

How to implement those restrictions ?

See current LSM hooks and potentially RFC that introduces LSM hooks for namespaces.

[RazeLighter777]

Namespace restriction is sometimes achieved through seccomp filters. However, because seccomp filters cannot dereference pointers, they cannot be used to restrict namespace creation via clone3(2). As a result, clone3(2) sometimes is entirely disabled (e.g., Docker's default seccomp profile that denies CLONE_NEWUSER).

Landlock could provide a way to restrict thoses without requiring a seccomp filter that completely denies clone3(2).

Unprivileged user namespaces also greatly increase the Linux kernel attack surface. Landlock could benefit from a mechanism to deny the creation of unprivileged user namespaces.

Landlock could add an access right for namespace creation (LANDLOCK_ACCESS_NS_CREATE?), with rules being ns_types. Handling this access right LANDLOCK_ACCESS_NS_CREATE could implicitly "scope" namespace installation to the domain as well, preventing a suitably privileged process from joining a namespace outside the domain's userns heirarchy.

This could be implemented with the hooks security_namespace_alloc and security_namespace_install in the patchset you referenced. 1

For security_namespace_alloc, check the ns_common->ns_type against the ruleset.

To scope namespace installation, we hook security_namespace_install, check if the namespace being installed belongs to the current domain's user namespace, via repeated calls to ns->ops->get_parent / ns_get_owner and compare them against the current task's cred->user_ns.

This would effectively allow users to not only control namespace creation, but also restrict privileged processes from joining namespaces outside the domain with a single access right. (similar to the proposal for implicitly scoping unix sockets)

[l0kod]

Looks good! I'm working on an initial RFC to start a discussion on the mailing list.

[l0kod]

RFC v1: https://lore.kernel.org/all/20260312100444.2609563-1-mic@digikod.net/