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

From: Casey Schaufler

Date: Wed Sep 02 2026 - 16:10:21 EST


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
>