Merge patch series "userns: keep the exec securebits"

Christian Brauner <brauner@kernel.org> says:

The exec securebits are meant to be set and locked by a service manager
so that nothing below it can turn them off again. But creating a user
namespace resets all securebits, locks included. So anyone who may
create a user namespace can shed them with a single
unshare(CLONE_NEWUSER), and joining one with setns() does the same.
That's pretty much everyone.

systemd gains a SecureBits= setting for the service manager itself. It
sets and locks the exec bits for everything it starts, so interpreters
that support AT_EXECVE_CHECK enforce the system's execution policy for
their scripts. With the reset "unshare -U python3 /tmp/x.py" gets
around all of that.

The other securebits are about how capabilities are computed and
resetting them in a new user namespace is fine. The exec bits grant
nothing. They're restrictions a task placed on itself, like
no_new_privs, which a user namespace doesn't drop either. So keep them
and their locks and keep resetting the rest.

I also keep the exec bits that aren't locked. fork() and execve()
preserve them and the task can clear them itself anyway, so dropping
them on unshare() would just be inconsistent.

The new selftests fail on mainline and pass with the fix. I think this
wants to go to stable, otherwise the locks don't mean much on any kernel
that has these bits.

* patches from https://patch.msgid.link/20261026-work-securebits-userns-v1-0-b35473fa1a34@kernel.org:
  selftests/exec: check that user namespaces keep the exec securebits
  userns: don't drop the exec securebits

Link: https://patch.msgid.link/20261026-work-securebits-userns-v1-0-b35473fa1a34@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

0 files changed, 0 insertions, 0 deletions