Re: [PATCH 2/2] LSM: Allow reservation of netlabel

[Casey Schaufler <casey@schaufler-ca.com>]

On 10/10/2025 12:53 PM, Stephen Smalley wrote:
> On Fri, Oct 10, 2025 at 11:09 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/9/2025 11:53 AM, Stephen Smalley wrote:
>>> On Wed, Oct 1, 2025 at 5:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> Allow LSMs to request exclusive access to the netlabel facility.
>>>> Provide mechanism for LSMs to determine if they have access to
>>>> netlabel. Update the current users of netlabel, SELinux and Smack,
>>>> to use and respect the exclusive use of netlabel.
>>>>
>>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>>>> ---
>>>> diff --git a/security/security.c b/security/security.c
>>>> index e59e3d403de6..9eca10844b56 100644
>>>> --- a/security/security.c
>>>> +++ b/security/security.c
>>>> @@ -289,6 +289,12 @@ static void __init lsm_set_blob_sizes(struct lsm_blob_sizes *needed)
>>>>                 else
>>>>                         blob_sizes.lbs_secmark = true;
>>>>         }
>>>> +       if (needed->lbs_netlabel) {
>>>> +               if (blob_sizes.lbs_netlabel)
>>>> +                       needed->lbs_netlabel = false;
>>>> +               else
>>>> +                       blob_sizes.lbs_netlabel = true;
>>>> +
>>> Same principle here - if a LSM wants to use netlabel, it may want to
>>> guarantee that it truly has exclusive access to it no matter what the
>>> LSM order is.
>> And if SELinux and Smack both shout "I gotta have it!" who wins?
>> Does the system fail to boot? Do you assign it to the first requestor,
>> as this patch does explicitly?
>>
>> If LSMs can't be equal in the eyes of the infrastructure, If one (e.g. SELinux)
>> always gets its way regardless of the end user intent, I have a problem with
>> the whole thing.
> End user intent is unlikely to be expressed as a silent side effect of
> LSM order.

But that's what we have now with the "first exclusive LSM" rule.
And the patch doesn't have a "silent" side effect. An LSM is informed
at initialization whether it can use secmarks. An LSM could even
decide to use secmarks if it has been told not to. That would be wrong,
and probably not upstream acceptable, but in security the wild and wacky
happens all too often.

> If a security module supports its use without the use of secmark
> and/or netlabel and the end user wants to assign one or both to
> another security module, that's fine.

That is what this patch implements.

> But some security modules may not function correctly (or at all) if
> secmark and/or netlabel are silently disabled on them, and the end
> user needs a better way to express intent.

I'm open to suggestions. Would boot options lsm.secmark and lsm.netlabel
be sufficient to address your concern?