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: <CAHC9VhTr_0XtFfp017vXmaQVm77kkN+4ZqxNqNnBOW6MpFQqkg@mail.gmail.com>
Date: Mon, 13 Oct 2025 18:11:48 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Stephen Smalley <stephen.smalley.work@...il.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 Fri, Oct 10, 2025 at 11:03 AM Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 10/9/2025 11:49 AM, Stephen Smalley wrote:
> > 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?
>
> But what if two LSMs insist on getting the secmark? The whole point
> is to make it possible to use multiple LSMs that what the feature at
> the same time.

My current thinking is that if two LSMs *insist* on access to the
secmark, one of them has to fail to load/initialize, even if that
means a panic on boot (we should flag that as an invalid config in
Kconfig).

Perhaps the solution is to have lbs_secmark as a tristate value: don't
use secmarks, would like access to secmarks, must have access to
secmarks.  Upon registration a LSM that requested "would like" could
check to see if they have been granted access and could adjust
accordingly.  A LSM that requested "must have" would fail to register
if the secmarks were already taken by a prior LSM.

> The limitation on a secmark being a u32 is a huge problem,
> and Paul has battled with the netdev people over it for years.

I suspect the only way forward at this point is to convert the secmark
field into an IDR* that we could use to point to a LSM security blob
that could store LSM specific structs for both secmarks and general
LSM state associated with a skb.  This would also allow us to do some
cool things in the forward path that we can't properly do now and
would make it much easier to handle a wider variety of packet level
access control scenarios.

It's on my todo list for <hand_waving>someday</hand_waving>, but if
somebody wanted to do it that would be awesome.  Just a word of
warning, this is not a quick task and it is probably only suited for
someone who already has a few netdev inflicted scars.

*I see that IDR is now deprecated in favor of XArray, I haven't looked
that closely at XArray but it looks workable too.

-- 
paul-moore.com