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] [day] [month] [year] [list]

Message-ID: <CAHC9VhSBxhiTvxPpHHqZJygDTTuMWOPFpQcoMSsvZD6Bueg0ZQ@mail.gmail.com>
Date: Mon, 13 Oct 2025 18:21:06 -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 2/2] LSM: Allow reservation of netlabel

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.

-- 
paul-moore.com