From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>,
eparis@redhat.com, linux-security-module@vger.kernel.org,
audit@vger.kernel.org
Cc: jmorris@namei.org, serge@hallyn.com, keescook@chromium.org,
john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
selinux@vger.kernel.org, Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH RFC 5/15] LSM: Single calls in secid hooks
Date: Tue, 4 Nov 2025 08:00:20 -0800 [thread overview]
Message-ID: <4c8a2252-5df3-451b-b6f5-e87cf7a161b9@schaufler-ca.com> (raw)
In-Reply-To: <ee015074a9019ef4725f7e613fd76f86@paul-moore.com>
On 10/14/2025 4:12 PM, Paul Moore wrote:
> On Jun 21, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>> security_socket_getpeersec_stream(), security_socket_getpeersec_dgram()
>> and security_secctx_to_secid() can only provide a single security context
>> or secid to their callers. Open code these hooks to return the first
>> hook provided. Because only one "major" LSM is allowed there will only
>> be one hook in the list, with the excepton being BPF. BPF is not expected
>> to be using these interfaces.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> security/security.c | 24 ++++++++++++++++++++----
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/security/security.c b/security/security.c
>> index db85006d2fd5..2286285f8aea 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -3806,8 +3806,13 @@ EXPORT_SYMBOL(security_lsmprop_to_secctx);
>> */
>> int security_secctx_to_secid(const char *secdata, u32 seclen, u32 *secid)
>> {
>> + struct lsm_static_call *scall;
>> +
>> *secid = 0;
>> - return call_int_hook(secctx_to_secid, secdata, seclen, secid);
>> + lsm_for_each_hook(scall, secctx_to_secid) {
>> + return scall->hl->hook.secctx_to_secid(secdata, seclen, secid);
>> + }
>> + return LSM_RET_DEFAULT(secctx_to_secid);
>> }
>> EXPORT_SYMBOL(security_secctx_to_secid);
> Two thoughts come to mind:
>
> If we are relying on BPF not using these hooks we should remove the BPF
> callback. It looks like the secctx_to_secid and socket_getpeersec_stream
> callbacks are already absent from the BPF LSM, so it's just a matter of
> working with the BPF folks to see if socket_getpeersec_dgram can be
> removed. If it can't be removed, you'll need to find another solution.
That should be doable. If BPF decides they want to use lsm_prop data
they already have a passel of work to do, and I see that they have
already suggested removing the BPF data from lsm_prop.
The socket_getpeersec_dgram interface uses secids, not lsm_prop, but
that's an artifact of networking attitude, not what's "right" for it.
> Instead of opening up the call_int_hook() wrapper here, what would it
> look like if we enforced the single callback rule at LSM registration
> time?
I have considered that approach in the past. It would require that
security_add_hooks() know which hooks are single callback and only
call lsm_static_call_init() if no LSM had requested the hook before.
This would be fairly straight forward and have the advantage of allowing
the infrastructure to report which single callback hooks have been
chosen and which disallowed. It does raise the question of whether the
LSM that requested the hook should be notified in the case it was
discarded. That's messy, as there are multiple single callback hooks,
and you could have a case where some are chosen and others disallowed.
I would go without notification, as it's hard to say what an LSM would
do with that information.
I'll give it a go in the next version.
>> @@ -4268,8 +4273,13 @@ EXPORT_SYMBOL(security_sock_rcv_skb);
>> int security_socket_getpeersec_stream(struct socket *sock, sockptr_t optval,
>> sockptr_t optlen, unsigned int len)
>> {
>> - return call_int_hook(socket_getpeersec_stream, sock, optval, optlen,
>> - len);
>> + struct lsm_static_call *scall;
>> +
>> + lsm_for_each_hook(scall, socket_getpeersec_stream) {
>> + return scall->hl->hook.socket_getpeersec_stream(sock, optval,
>> + optlen, len);
>> + }
>> + return LSM_RET_DEFAULT(socket_getpeersec_stream);
>> }
>>
>> /**
>> @@ -4289,7 +4299,13 @@ int security_socket_getpeersec_stream(struct socket *sock, sockptr_t optval,
>> int security_socket_getpeersec_dgram(struct socket *sock,
>> struct sk_buff *skb, u32 *secid)
>> {
>> - return call_int_hook(socket_getpeersec_dgram, sock, skb, secid);
>> + struct lsm_static_call *scall;
>> +
>> + lsm_for_each_hook(scall, socket_getpeersec_dgram) {
>> + return scall->hl->hook.socket_getpeersec_dgram(sock, skb,
>> + secid);
>> + }
>> + return LSM_RET_DEFAULT(socket_getpeersec_dgram);
>> }
>> EXPORT_SYMBOL(security_socket_getpeersec_dgram);
>>
>> --
>> 2.47.0
> --
> paul-moore.com
next prev parent reply other threads:[~2025-11-04 16:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250621171851.5869-1-casey.ref@schaufler-ca.com>
2025-06-21 17:18 ` [RFC PATCH 00/15] LSM: No exclusive LSMs Casey Schaufler
2025-06-21 17:18 ` [RFC PATCH 01/15] Audit: Create audit_stamp structure Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 1/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 02/15] LSM: security_lsmblob_to_secctx module selection Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 2/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 03/15] Audit: Add record for multiple task security contexts Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 3/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 04/15] Audit: Add record for multiple object contexts Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 4/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 05/15] LSM: Single calls in secid hooks Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 5/15] " Paul Moore
2025-11-04 16:00 ` Casey Schaufler [this message]
2025-06-21 17:18 ` [RFC PATCH 06/15] LSM: Exclusive secmark usage Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 6/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 07/15] Audit: Call only the first of the audit rule hooks Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 7/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 08/15] AppArmor: Remove the exclusive flag Casey Schaufler
2025-06-21 17:18 ` [RFC PATCH 09/15] LSM: Add mount opts blob size tracking Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC 9/15] " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 10/15] LSM: allocate mnt_opts blobs instead of module specific data Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 11/15] LSM: Infrastructure management of the mnt_opts security blob Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 12/15] LSM: Allow reservation of netlabel Casey Schaufler
2025-10-14 23:12 ` [PATCH RFC " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 13/15] LSM: restrict security_cred_getsecid() to a single LSM Casey Schaufler
2025-10-14 23:13 ` [PATCH RFC " Paul Moore
2025-06-21 17:18 ` [RFC PATCH 14/15] Smack: Remove LSM_FLAG_EXCLUSIVE Casey Schaufler
2025-06-21 17:18 ` [RFC PATCH 15/15] LSM: Remove exclusive LSM flag Casey Schaufler
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=4c8a2252-5df3-451b-b6f5-e87cf7a161b9@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=audit@vger.kernel.org \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stephen.smalley.work@gmail.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®