All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bradley Morgan <bradley.morgan@linux.dev>
To: Serge Hallyn <serge@hallyn.com>
Cc: "Christian Brauner" <brauner@kernel.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Josef Bacik" <josef@toxicpanda.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] userns: security: Inform LSMs of capability check during userns creation
Date: Sat, 14 Nov 2026 14:44:24 +0000	[thread overview]
Message-ID: <5862E641-C0F8-45B2-B340-DF4506AC9FAF@linux.dev> (raw)
In-Reply-To: <0c403a09-38cf-4953-a73a-ee57837b3799@hallyn.com>

On 14 November 2026 14:34:07 GMT, Serge Hallyn <serge@hallyn.com> wrote:
>Nov 13, 2026 15:54:37 Bradley Morgan <bradley.morgan@linux.dev>:
>
>> On 13 November 2026 21:39:33 GMT, "Serge E. Hallyn" <serge@hallyn.com>
>> wrote:
>>> On Wed, Nov 11, 2026 at 08:58:14PM +0000, Bradley Morgan wrote:
>>>> Right now security_capable() gets called in create_user_ns() to
>snapshot
>>>> whether the parent could setfcap, but the LSM gets zero context on
>where
>>>> the check actually came from. It is the same story as setid: without a
>>>> dedicated flag, security modules cannot tell this apart from regular
>>>> capability checks.
>>>>
>>>> Add CAP_OPT_USERNS_CREATE and pass it along from create_user_ns().
>>>
>>> This should be patch 1/N in a set that introduces a user of it
>>> in some lsm.
>>
>> hmm. Did you read Christians suggestion?
>
>I did, when he first sent it. Actually it seems to me that what the lsm
>would really like to know is that this is not for an immediate use of
>setfcap, but possible future use. But that doesn't really matter. I wasn't
>judging the patch. I was just going by what i believe is general lsm
>subsystem policy.

( my word wrapping client did not like that message :( )

hmm, it's pre-reqed over the patch as on the lore link, so Christian may
want to have a look at this obe

>
>> Let's see if Christian or anyone
>> else could suggest a nice little lsm user for this.
>>
>> If nobody responds, in coming days, I'll go and find and do a user for
>it.
>>
>>>
>>>> Suggested-by: Christian Brauner <brauner@kernel.org>
>>>> Link:
>>>
>https://lore.kernel.org/all/20261111-kommt-gischt-ohnedies-469998d2f219@brauner/
>>>> Signed-off-by: Bradley Morgan <bradley.morgan@linux.dev>
>>>> ---
>>>> Thanks Christian for the suggestion :).
>>>> ---
>>>> include/linux/security.h | 2 ++
>>>> kernel/user_namespace.c  | 3 ++-
>>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/linux/security.h b/include/linux/security.h
>>>> index 40831fab54709..d24666a0b4833 100644
>>>> --- a/include/linux/security.h
>>>> +++ b/include/linux/security.h
>>>> @@ -75,6 +75,8 @@ struct nsset;
>>>> #define CAP_OPT_NOAUDIT BIT(1)
>>>> /* If capable is being called by a setid function */
>>>> #define CAP_OPT_INSETID BIT(2)
>>>> +/* Is capable being called from the user namespace creation path? */
>>>> +#define CAP_OPT_USERNS_CREATE BIT(3)
>>>>
>>>> /* LSM Agnostic defines for security_sb_set_mnt_opts() flags */
>>>> #define SECURITY_LSM_NATIVE_LABELS 1
>>>> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>>>> index 57b7f10be74e1..37480f6d8369f 100644
>>>> --- a/kernel/user_namespace.c
>>>> +++ b/kernel/user_namespace.c
>>>> @@ -134,7 +134,8 @@ int create_user_ns(struct cred *new)
>>>>      * audit: the creator may never map uid 0.
>>>>      */
>>>>     ns->parent_could_setfcap =
>>>> -       !security_capable(new, parent_ns, CAP_SETFCAP,
>CAP_OPT_NOAUDIT);
>>>> +       !security_capable(new, parent_ns, CAP_SETFCAP,
>>>> +                 CAP_OPT_NOAUDIT | CAP_OPT_USERNS_CREATE);
>>>>
>>>>     ret = ns_common_init(ns);
>>>>     if (ret)
>>>> --
>>>> 2.53.0
>>>
>>
>> --- Thanks!
>
>

--- Thanks!

      reply	other threads:[~2026-11-14 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 20:58 [PATCH] userns: security: Inform LSMs of capability check during userns creation Bradley Morgan
2026-11-13 21:39 ` Serge E. Hallyn
2026-11-13 21:54   ` Bradley Morgan
2026-11-14 14:34     ` Serge Hallyn
2026-11-14 14:44       ` Bradley Morgan [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=5862E641-C0F8-45B2-B340-DF4506AC9FAF@linux.dev \
    --to=bradley.morgan@linux.dev \
    --cc=brauner@kernel.org \
    --cc=jmorris@namei.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /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.