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

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: <613960bd-1ba5-4503-88ec-5d13234b2bcb@schaufler-ca.com>
Date: Tue, 4 Nov 2025 09:07:41 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.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, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH 2/2] LSM: Allow reservation of netlabel

On 10/13/2025 3:21 PM, Paul Moore wrote:
> On Fri, Oct 10, 2025 at 5:11 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 10/10/2025 12:53 PM, Stephen Smalley wrote:
>>> On Fri, Oct 10, 2025 at 11:09 AM Casey Schaufler <casey@...aufler-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@...aufler-ca.com> wrote:
> ..
>
>>> 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.
> This is the point I was trying to make in patch 1/2 with secmarks, but
> Stephen has captured the idea much better in the sentence above.  To
> be clear, the argument applies to both secmarks and NetLabel.
>
>> I'm open to suggestions. Would boot options lsm.secmark and lsm.netlabel
>> be sufficient to address your concern?
> No.  Please no.  We already have two LSM initialization related
> command line parameters, and one of them is pretty broken and very
> confusing in the new world of multiple LSMs (as an aside, does someone
> want to kick off the work to deprecate "security=?").  Maybe we have
> to go this route eventually, but let's keep it simple for right now; I
> don't want to add a lot of user-visible APIs for something that is
> pretty niche.
>
> If you absolutely can't live with the "first one gets it" approach,
> look at the no/wants/must idea in my patch 1/2 comments.  It would
> require work in the individual LSMs to support it, but I'd rather try
> that route first.

I'm fine (for now, at least) with the "first LSM" approach, which is
what I have implemented. What I *am* afraid of is SELinux deciding that
it can only ever possibly work if it is the "first LSM". Best I can tell,
there's no reason for it beyond "configuration is hard". Which it is,
but we're already there.