[PATCH 1/2] LSM: Exclusive secmark usage

[Casey Schaufler]

On 10/13/2025 3:11 PM, Paul Moore wrote:
> On Fri, Oct 10, 2025 at 11:03 AM Casey Schaufler <casey at schaufler-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 at schaufler-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 at schaufler-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).

That's sensible, but why should an LSM be allowed to insist on access
to the secmark? Best I can tell, SELinux rarely uses it in real life.
Smack currently always uses it, but that's fixed in this patch set.
I would be perplexed by a "dog in the manger" attitude on the part of
any maintainers. 

>
> 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.

I would be unhappy if any existing LSM decided it "must have" secmarks.
I can imagine a LSM that really required the secmark, but it would have
a tough time getting accepted.

>> 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 expect to be dead, or at least suffering serious memory loss,
by the time that work can be done. :(


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