linux-kernel - Re: [PATCH 1/2] LSM: Exclusive secmark usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEjxPJ7M4qySg+ZMujTqMQFSncWNbG21W+kpLzji6c4F+hyprA@mail.gmail.com>
Date: Thu, 9 Oct 2025 14:49:23 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: paul@...l-moore.com, linux-security-module@...r.kernel.org, 
	jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org, 
	john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp, 
	linux-kernel@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH 1/2] LSM: Exclusive secmark usage

On Wed, Oct 1, 2025 at 5:56 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>
> The network secmark can only be used by one security module
> at a time. Establish mechanism to identify to security modules

a mechanism to inform security modules?

> whether they have access to the secmark. SELinux already
> incorparates mechanism, but it has to be added to Smack and

incorporates

> AppArmor.
>
> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
> ---
>  include/linux/lsm_hooks.h        |  1 +
>  security/apparmor/include/net.h  |  5 +++++
>  security/apparmor/lsm.c          |  7 ++++---
>  security/security.c              |  6 ++++++
>  security/selinux/hooks.c         |  4 +++-
>  security/smack/smack.h           |  5 +++++
>  security/smack/smack_lsm.c       |  3 ++-
>  security/smack/smack_netfilter.c | 10 ++++++++--
>  8 files changed, 34 insertions(+), 7 deletions(-)
>

> diff --git a/security/security.c b/security/security.c
> index ad163f06bf7a..e59e3d403de6 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -283,6 +283,12 @@ static void __init lsm_set_blob_sizes(struct lsm_blob_sizes *needed)
>         lsm_set_blob_size(&needed->lbs_xattr_count,
>                           &blob_sizes.lbs_xattr_count);
>         lsm_set_blob_size(&needed->lbs_bdev, &blob_sizes.lbs_bdev);
> +       if (needed->lbs_secmark) {
> +               if (blob_sizes.lbs_secmark)
> +                       needed->lbs_secmark = false;
> +               else
> +                       blob_sizes.lbs_secmark = true;
> +       }

So if I understand correctly, the first LSM to register with
lbs_secmark set wins.
Not sure that's a great idea - seemingly some LSMs may want to insist
that they get to use secmark regardless of registration order?