From: Casey Schaufler <casey@schaufler-ca.com>
To: casey@schaufler-ca.com, paul@paul-moore.com,
linux-security-module@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, selinux@vger.kernel.org
Subject: [RFC PATCH 0/3] LSM: Hook registration exculsivity
Date: Wed, 25 Feb 2026 11:21:40 -0800 [thread overview]
Message-ID: <20260225192143.14448-1-casey@schaufler-ca.com> (raw)
In-Reply-To: 20260225192143.14448-1-casey.ref@schaufler-ca.com
This patch set represents a reasonably radical change to the LSM
stacking model. The notion of an "exclusive" LSM begins to give
way to exclusive LSM hooks. Instead of disallowing more than one
exclusive LSM, individual hooks are marked as exclusive and only
one is allowed to be registered. Subsequent LSMs that attempt to
register these hooks are denied them. This can have consequences.
The hooks relative to secmarks have been used here to demonstrate
that the scheme can work, and that it isn't always as clean as
one might like.
Please comment fully. Quite a bit of tinkering went into devising
this approach, which is intended to address a number of concerns.
Add a flags field to the LSM hook definition.
The first LSM that requests a hook with the LSM_FLAG_EXCLUSIVE flag
will be the only LSM that can register any hook thus marked.
Attempts by other LSMs to register such hooks are ignored.
Direct access to skb->secmark within LSMs are wrapped with a
helper function lsm_secmark_from_skb(). This function checks to see
if the secmark related LSM hooks, which are marked LSM_FLAG_EXCLUSIVE,
are registered by the calling LSM. If they are, the secmark value is
returned. Otherwise, the invalid secmark value 0 is returned.
Future implementations of lsm_secmark_from_skb() could use some
form of secmark encoding that would allow more than one LSM to
use secmarks at the same time.
The LSMs that currently support use of secmarks are taught how to
identify if they are allowed use of the secmark. Each sets secmark values
differently. At initialization the LSMs have the opportunity to
take steps to ensure correct behavior if they don't have secmark access.
https://github.com/cschaufler/lsm-stacking#secmark-6.19-rc8-v1
Casey Schaufler (3):
LSM: add a flags field to the LSM hook definitions
LSM: Enforce exclusive hooks
LSM: Reserve use of secmarks
include/linux/bpf_lsm.h | 2 +-
include/linux/lsm_hook_defs.h | 614 ++++++++++++++++---------------
include/linux/lsm_hooks.h | 4 +-
include/linux/security.h | 3 +
kernel/bpf/bpf_lsm.c | 10 +-
security/apparmor/lsm.c | 24 +-
security/bpf/hooks.c | 2 +-
security/lsm_init.c | 66 ++++
security/security.c | 21 +-
security/selinux/hooks.c | 35 +-
security/selinux/ss/services.c | 3 +
security/smack/smack_lsm.c | 6 +-
security/smack/smack_netfilter.c | 6 +
13 files changed, 473 insertions(+), 323 deletions(-)
--
2.52.0
next parent reply other threads:[~2026-02-25 19:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260225192143.14448-1-casey.ref@schaufler-ca.com>
2026-02-25 19:21 ` Casey Schaufler [this message]
2026-02-25 19:21 ` [RFC PATCH 1/3] LSM: add a flags field to the LSM hook definitions Casey Schaufler
2026-02-25 19:21 ` [RFC PATCH 2/3] LSM: Enforce exclusive hooks Casey Schaufler
2026-02-25 19:21 ` [RFC PATCH 3/3] LSM: Reserve use of secmarks 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=20260225192143.14448-1-casey@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.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