Re: [PATCH 0/7] Change skb secmarks to x-array indexes

On 8/31/2026 3:37 PM, Casey Schaufler wrote:

This patch set was incorrectly sourced, and contains errors.
Please ignore and accept my apologies for the noise.

> When security secmarks were added to the Linux network stack there was
> only one Linux Security Module (LSM), SELinux.  SELinux already used the
> concept of a security ID (secid) as the representation of the security
> information about a system subject (active entity) or object (passive
> entity). Adding a container for a secid, the secmark, to the sk_buff
> structure allowed for efficient transmission of the SELinux secid for
> socket based access controls.
>
> Subsequent LSMs have chosen to represent security information more
> directly. Smack and AppArmor use pointers to structures containing
> relevant information. Alas, these pointers do not fit in the u32 secmark
> on most modern architectures. These LSMs are required to provide a secid
> mapping to use secmarks.
>
> Even with all LSMs that use secmarks having a secid to reference the
> security information the mechanism is imperfect. A system that wants
> to use multiple LSMs that use secmarks is constrained by the size
> of the secmark. There is no rational way to fit multiple secids in a
> secmark. While it would be possible to allow one LSM to use the secmark
> and any others to be told it is unavailable, this has been deemed an
> unacceptable limitation.
>
> There is a lsm_prop structure available that contains security information
> for any LSM that maintains it. The secmark cannot, unfortunately,
> contain one. Instead, an x-array of lsm_prop structures is maintained,
> and the index (secxa) is used in the secmark instead of the single LSM
> restricted secid.
>
> Uses of security_secctx_to_secid() have been changed to
> security_secctx_to_lsmprop() in the netfilter and iptables code.
> The security_secmark_relabel_packet() function has been updated to accept
> an lsm_prop pointer rather than a secid.
> To support multiple LSMs using a secmark it is necessary to re-evaluate
> which lsm_prop structure represents the current security information
> at each step where the secmark can be set. Smack sets the secmark for
> every packet.  Netfilter, used by SELinux, Smack and AppArmor, will set
> the secmark on selected packets at a later time. If Smack and AppArmor
> are active on a system Smack will set the secmark initially, and AppArmor
> may reset it by netfilter rule.
>
> v2: Address issues raised by Sashiko
>  - Configuration option insufficiencies
>  - Locking issues
>
> https://github.com/cschaufler/lsm-stacking#secmark-xa-7.2-rc7-v2
>
> Casey Schaufler (7):
>   net, smack: Create a function to set secmarks
>   LSM: Implement x array functions for secmarks
>   LSM: Two hooks for manipulating struct lsm_prop
>   SELinux: hooks for secctx_to_lsmprop and update_lsmprop
>   Smack: hooks for secctx_to_lsmprop and update_lsmprop
>   Apparmor: hooks for secctx_to_lsmprop and update_lsmprop
>   net, lsm: Change skb secmarks to x-array indexes
>
>  include/linux/lsm_hook_defs.h     |   6 +-
>  include/linux/lsm_secxa.h         |  33 ++++++++
>  include/linux/security.h          |  20 ++++-
>  net/netfilter/nfnetlink_queue.c   |  12 ++-
>  net/netfilter/nft_meta.c          |  20 +++--
>  net/netfilter/xt_CONNSECMARK.c    |   3 +-
>  net/netfilter/xt_SECMARK.c        |  19 +++--
>  security/Makefile                 |   1 +
>  security/apparmor/include/secid.h |   4 +
>  security/apparmor/lsm.c           |   2 +
>  security/apparmor/net.c           |   8 +-
>  security/apparmor/secid.c         |  21 +++++
>  security/lsm_secxa.c              | 128 ++++++++++++++++++++++++++++++
>  security/security.c               |  38 ++++++++-
>  security/selinux/hooks.c          |  87 +++++++++++++++++---
>  security/smack/smack_lsm.c        |  43 +++++++++-
>  security/smack/smack_netfilter.c  |  11 ++-
>  17 files changed, 418 insertions(+), 38 deletions(-)
>  create mode 100644 include/linux/lsm_secxa.h
>  create mode 100644 security/lsm_secxa.c
>