Linux Security Modules development
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: paul@paul-moore.com, linux-security-module@vger.kernel.org,
	pablo@netfilter.org, fw@strlen.de, phil@nwl.cc
Cc: linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	coreteam@netfilter.org, 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,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/7] Change skb secmarks to x-array indexes
Date: Wed, 2 Sep 2026 12:37:55 -0700	[thread overview]
Message-ID: <8c4e0734-0775-4680-aa69-f6f35345c02d@schaufler-ca.com> (raw)
In-Reply-To: <20260831223748.4304-1-casey@schaufler-ca.com>

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
>

  parent reply	other threads:[~2026-09-02 19:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260831223748.4304-1-casey.ref@schaufler-ca.com>
2026-08-31 22:37 ` [PATCH 0/7] Change skb secmarks to x-array indexes Casey Schaufler
2026-08-31 22:37   ` [PATCH 1/7] net, smack: Create a function to set secmarks Casey Schaufler
2026-08-31 22:37   ` [PATCH 2/7] LSM: Implement x array functions for secmarks Casey Schaufler
2026-08-31 22:37   ` [PATCH 3/7] LSM: Two hooks for manipulating struct lsm_prop Casey Schaufler
2026-08-31 22:37   ` [PATCH 4/7] SELinux: hooks for secctx_to_lsmprop and update_lsmprop Casey Schaufler
2026-08-31 22:37   ` [PATCH 5/7] Smack: " Casey Schaufler
2026-08-31 22:37   ` [PATCH 6/7] Apparmor: " Casey Schaufler
2026-08-31 22:37   ` [PATCH 7/7] net, lsm: Change skb secmarks to x-array indexes Casey Schaufler
2026-09-02 19:37   ` Casey Schaufler [this message]
     [not found] <20260813204854.19211-1-casey.ref@schaufler-ca.com>
2026-08-13 20:48 ` [PATCH 0/7] " 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=8c4e0734-0775-4680-aa69-f6f35345c02d@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=coreteam@netfilter.org \
    --cc=fw@strlen.de \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=paul@paul-moore.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=phil@nwl.cc \
    --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