Dynamic No New Privileges (NNP) via bpf

[brauner]

Dynamic No New Privileges (NNP) via bpf

On newer systems the use of privilege escalating binaries (suid, sgid, file capabilities) can be avoided. This model is illustrated in systemd's run0 tool.

So it is possible to turn on PR_SET_NO_NEW_PRIVS (NNP) for systemd itself and thus for every process on the system. However, that breaks sandboxed workloads. Sandboxed workloads such as containers may run a single process without a full-fledged daemon that could supervise privileged operations. In such cases executing privilege escalating binaries must be allowed.

Ideally sandboxes that require execution of privilege escalating binaries must use a user namespace with a non-identity idmapping.

Instead of revamping the fairly inflexible NNP implementation, execution of privilege escalating binaries should be supervised by a bpf LSM.

When a privilege escalating binary is executed in the initial user namespace the bpf LSM program will cause the kernel to skip elevating privileges and instead execute the binary with the caller's privileges. This is equivalent to the NNP behavior.

If a privilege escalating binary is executed in a non-initial user namespace the bpf LSM program will allow the kernel to escalate the caller's privileges to a higher privilege level.

This will allow unprivileged containers to execute privilege escalating binaries but completely isolate regular services from doing so.

This can of course be configurable on a per-service basis if needed.

This will require hooking up a new security hook into the kernel's exec codepath.

Use-Case: Wean all of userspace off of privilege escalating binaries.

Maybe @thejh has some thoughts here as well as @poettering and @DaanDeMeyer and @cyphar.

[thejh]

I assume this BPF hook would not affect any task_no_new_privs() checks except for influencing the exec path? I guess you'd basically have to split existing task_no_new_privs() checks into "has NNP for purposes of limiting privilege gain on exec via setuid/setgid/fscaps/selinux transition/apparmor transition/smack transition" (which the BPF hook could force to "yes" but can't force to "no") and "has NNP for purposes of allowing process mutations that will persist across execve()" (which the BPF hook couldn't influence)?

In that case, I think adding such an API would be safe.

(FYI, from what I remember, Chrome currently wants to be able to either execute setuid binaries or create user namespaces for its sandbox; if both are blocked, I think it might not launch.)