Overview and Recent Developments: Namespaces and Capabilities
Reviews overview and Recent Developments: Namespaces and Capabilities and evaluates key implications for security practitioners.
Summary
### Overview In this kernel subsystem presentation, Christian (an engineer on the LXC and LXD team at Canonical) provides an update on Linux namespaces and capabilities, tracking developments from Linux 4.10 through 4.18 as well as active and future patch sets. Capabilities divide root privilege into distinct units (e.g., CAP_SYS_ADMIN, CAP_NET_ADMIN) to delegate privilege safely, while namespaces provide lightweight virtualization isolating specific system aspects across seven current types: mount, PID, UTS, IPC, cgroup, network, and user namespaces.
### Key Topics - **Capabilities & Libcap**: Release of libcap with full ambient capability support and namespace filesystem capability support, with Andrew Morgan resuming maintenance. - **User Namespaces & Privilege Separation**: Unlike other namespaces that lack inherent security guarantees, user namespaces isolate root privileges via UID/GID mapping, nested user namespaces, and owning user namespaces that scope capability checks. - **Evolution across Kernel 4.10–4.18**: - *4.10*: Infrastructure for mounts from non-initial user namespaces; user_ns owner added to `mm_struct` for ptrace permission checks across exec; ioctl to query socket network namespaces. - *4.11*: Limits on inotify instances per user namespace to prevent global resource exhaustion; ioctls to query namespace hierarchies (`NS_GET_USERNS`, parent namespace retrieval). - *4.12*: Exposing `pid_ns_for_children` in proc for CRIU checkpoint/restore; proper PID translation for FUSE in PID namespaces. - *4.13*: Drastic unmount performance improvements for overlapping mount trees (reduced from up to 60s to 0.06s); `nsdelegate` mount option making cgroup namespaces delegation boundaries for root. - *4.14*: Namespaced filesystem capabilities (VFS capabilities) tracking root UIDs to prevent unprivileged privilege escalation. - *4.15*: Bumping UID/GID mapping extent limits from 5 to 340 (fitting within a cache line) with minimal overhead. - *4.16*: Querying peer network namespaces using netlink identifiers (`RTM_NEWLINK`, `RTM_DELLINK`, `RTM_SETLINK`) without requiring `setns`. - *4.17*: Unprivileged FUSE mount compatibility work with IMA; fix for `devpts` bind mounts; uevent injection via netlink into network namespaces (userspace device namespaces). - *4.18*: Enabling unprivileged mounts and FUSE mounts from user namespaces; changing `mknod` checks while applying `SB_I_NODEV` super block restrictions (which introduced regressions for runtimes expecting usable device nodes).
### Technical Details & Discussions Active proposals discussed include time namespaces, path resolution restrictions (`AT_BENEATH`, `AT_NO_SYMLINKS`, `resolveat`), querying peer network namespaces via `RTM_GETADDR`/`RTM_GETLINK`, and David Howells' new Mount API. Future work highlighted by the speaker covers recursive read-only bind mounts, reversible unmounts using tuck/tack mounts, and proposed ioctls such as `NS_IS_INITIAL` (`NS_INIT`) and `NS_ACCESS` to verify namespace ownership and device privileges.
### Takeaways While user namespaces and capability scoping have made running unprivileged containers significantly more viable, kernel security relies heavily on correct ownership checks and preventing resource exhaustion. Unprivileged filesystem mounts remain tightly constrained due to filesystem-level security risks against malicious images, with FUSE standing as one of the few permitted implementations.
Related talks
The Linux Foundation·33 min
Kees Cook
Provides overview and Recent Developments: Kernel Self-Protection Project and evaluates key implications for security practitioners.
The Linux Foundation·25 min
Jarkko Sakkinen
Examines overview and Recent Developments: TPM and evaluates key implications for security practitioners.
The Linux Foundation·35 min
David Howells
Provides overview and Recent Developments of Keyrings Subsystem and evaluates key implications for security practitioners.


