From: Serge Hallyn <serge@hallyn.com>
To: Bradley Morgan <bradley.morgan@linux.dev>
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 08:34:07 -0600 [thread overview]
Message-ID: <0c403a09-38cf-4953-a73a-ee57837b3799@hallyn.com> (raw)
In-Reply-To: <4A0D804A-1199-4402-91EE-E37E8D6EA9E7@linux.dev>
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.
> 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!
next prev parent reply other threads:[~2026-11-14 14:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 20:58 Bradley Morgan
2026-11-13 21:39 ` Serge E. Hallyn
2026-11-13 21:54 ` Bradley Morgan
2026-11-14 14:34 ` Serge Hallyn [this message]
2026-11-14 14:44 ` Bradley Morgan
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=0c403a09-38cf-4953-a73a-ee57837b3799@hallyn.com \
--to=serge@hallyn.com \
--cc=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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®