All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, "Mickaël Salaün" <mic@digikod.net>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	"Jann Horn" <jannh@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 0/2] userns: keep the exec securebits
Date: Sun, 1 Nov 2026 11:08:30 -0600	[thread overview]
Message-ID: <audyDljs8nV8vA6h@hallyn.com> (raw)
In-Reply-To: <20261026-work-securebits-userns-v1-0-b35473fa1a34@kernel.org>

On Mon, Oct 26, 2026 at 09:53:28PM +0100, Christian Brauner wrote:
> 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.
> 
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

thanks, makes sense to me.

Reviewed-by: Serge Hallyn <serge@hallyn.com>

for both.

> ---
> Christian Brauner (2):
>       userns: don't drop the exec securebits
>       selftests/exec: check that user namespaces keep the exec securebits
> 
>  Documentation/userspace-api/check_exec.rst |  4 ++
>  kernel/user_namespace.c                    |  5 +-
>  tools/testing/selftests/exec/check-exec.c  | 83 ++++++++++++++++++++++++++++++
>  3 files changed, 91 insertions(+), 1 deletion(-)
> ---
> base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7
> change-id: 20261026-work-securebits-userns-6070b18a9cda

      parent reply	other threads:[~2026-11-01 17:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 20:53 [PATCH 0/2] userns: keep the exec securebits Christian Brauner
2026-10-26 20:53 ` [PATCH 1/2] userns: don't drop " Christian Brauner
2026-10-29 11:37   ` Mickaël Salaün
2026-10-26 20:53 ` [PATCH 2/2] selftests/exec: check that user namespaces keep " Christian Brauner
2026-11-01 17:08 ` Serge E. Hallyn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=audyDljs8nV8vA6h@hallyn.com \
    --to=serge@hallyn.com \
    --cc=brauner@kernel.org \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mic@digikod.net \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.