[PATCH RFC 3/3] LSM: Reserve use of secmarks

[Casey Schaufler]

On 4/23/2026 6:19 PM, Paul Moore wrote:
> On Feb 25, 2026 Casey Schaufler <casey at schaufler-ca.com> wrote:
>> Use of "exclusive" LSM hooks are limited to the first LSM registering
>> them. These hooks include those use to process network secmarks.
>> The hooks required to process secmarks are flagged with LSM_FLAG_EXCLUSIVE
>> in their definitions. This includes secid_to_secctx and secctx_to_secid,
>> which are used by netfilter.
>>
>> The various LSMs that use secmarks are updated to detect whether
>> they are providing exclusive hooks, and to eschew the use of secmarks
>> if they are not.
>>
>> SELinux has a peculiar behavior in that it may decide that it
>> must have network controls, but only after policy is loaded.
>> This patch includes a warning should policy capability alwaysnetwork
>> be set when another LSM holds the exclusive hooks. It has been
>> suggested that SELinux would consider this a fatal condition, in
>> which case a panic might be a favored, if draconian, option.
>>
>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
>> ---
>>  include/linux/lsm_hook_defs.h    | 12 +++++------
>>  include/linux/security.h         |  1 +
>>  security/apparmor/lsm.c          | 24 ++++++++++++++++------
>>  security/security.c              | 15 ++++++++++++++
>>  security/selinux/hooks.c         | 35 ++++++++++++++++++++++++--------
>>  security/selinux/ss/services.c   |  3 +++
>>  security/smack/smack_lsm.c       |  6 ++++--
>>  security/smack/smack_netfilter.c |  6 ++++++
>>  8 files changed, 80 insertions(+), 22 deletions(-)
> ..
>
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index e3c137a1b30a..638436b9b748 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -326,6 +326,7 @@ int unregister_blocking_lsm_notifier(struct notifier_block *nb);
>>  extern int security_init(void);
>>  extern int early_security_init(void);
>>  extern u64 lsm_name_to_attr(const char *name);
>> +extern u32 lsm_secmark_from_skb(struct sk_buff *skb, const u64 lsmid);
>>  
>>  /* Security operations */
>>  int security_binder_set_context_mgr(const struct cred *mgr);
>> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
>> index a87cd60ed206..2ce0d9a73973 100644
>> --- a/security/apparmor/lsm.c
>> +++ b/security/apparmor/lsm.c
>> @@ -1511,9 +1511,11 @@ static int apparmor_socket_shutdown(struct socket *sock, int how)
>>  static int apparmor_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
>>  {
>>  	struct aa_sk_ctx *ctx = aa_sock(sk);
>> +	u32 secmark;
>>  	int error;
>>  
>> -	if (!skb->secmark)
>> +	secmark = lsm_secmark_from_skb(skb, LSM_ID_APPARMOR);
>> +	if (!secmark)
>>  		return 0;
>>  
>>  	/*
> ..
>
>> diff --git a/security/security.c b/security/security.c
>> index 25e7cfc96f20..754b16004677 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -4509,6 +4509,21 @@ void security_inet_conn_established(struct sock *sk,
>>  }
>>  EXPORT_SYMBOL(security_inet_conn_established);
>>  
>> +/**
>> + * lsm_secmark_from_skb - secid for the specified LSM from the packet
>> + * @skb: the packet
>> + * @lsm: which LSM is asking
>> + *
>> + * If the specified LSM has use of the secmark, return its value.
>> + * Otherwise, return the invalid secid 0.
>> + */
>> +u32 lsm_secmark_from_skb(struct sk_buff *skb, const u64 lsmid)
>> +{
>> +	if (lsmid == lsm_exclusive_hooks)
>> +		return skb->secmark;
>> +	return 0;
>> +}
> Ooof.  Not a fan.  A better way to handle this would be to like I
> mentioned in my comments on patch 2/3: have the LSM detect that it lost
> the LSM_FLAG_EXCLUSIVE battle at callback registration time and do
> whatever adjustments are necessary at init time.  In a number of cases I
> believe that simply not registering the callback will be sufficient.

In no case (AppArmor, Smack, SELinux) will that be sufficient. All
access skb->secmark directly. The hooks that use the secmark also use
other mechanisms (e.g. netlabel) to obtain security attributes.

> If the only way to solve this is via runtime checks like this,
> unfortunately my answer is going to be "no".

OK. I hear you.

> .. and of course the proper way to solve this for secmark is to just
> do the idr/xarray conversion for secmarks so every LSM can have their
> own secmark.  Yes, it does require some work, but to be honest I think
> you've spent more time avoiding that work then it would be to just do
> it.  I'm growing increasing inclined to simply state that this is the
> only solution I'm going to accept.

Thank you for the clarity. If you happen to have a preferred example of
how idr/xarray is used I expect that we can reduce the review cycle of
such an implementation.

... Or, if there's someone out there who's itching to get involved and
eager to tackle a moderately complicated integration effort, I'd happily
outline the pain points.

>
> --
> paul-moore.com

With that I think this RFC has been useful in that the LSM define flag
scheme might be useful in the future, but doesn't address the task at
hand.