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

[Paul Moore <paul@paul-moore.com>]

On Feb 25, 2026 Casey Schaufler <casey@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@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.

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

... 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.

--
paul-moore.com