linux-kernel - Re: [PATCH v3 4/5] Audit: multiple subject lsm values for 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: <5a220cb2-17ef-4bc6-813b-5ae5c7818d97@schaufler-ca.com>
Date: Wed, 30 Apr 2025 13:48:48 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.com>
Cc: eparis@...hat.com, linux-security-module@...r.kernel.org,
 audit@...r.kernel.org, jmorris@...ei.org, serge@...lyn.com,
 keescook@...omium.org, john.johansen@...onical.com,
 penguin-kernel@...ove.sakura.ne.jp, stephen.smalley.work@...il.com,
 linux-kernel@...r.kernel.org, selinux@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v3 4/5] Audit: multiple subject lsm values for netlabel

On 4/30/2025 11:51 AM, Paul Moore wrote:
> On Wed, Apr 30, 2025 at 12:25 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 4/24/2025 3:18 PM, Paul Moore wrote:
>>> On Mar 19, 2025 Casey Schaufler <casey@...aufler-ca.com> wrote:
>>>> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx().
>>>> This is used in netlabel auditing to provide multiple subject security
>>>> contexts as necessary.
>>>>
>>>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>>>> ---
>>>>  include/linux/audit.h        |  7 +++++++
>>>>  kernel/audit.c               | 28 +++++++++++++++++++++-------
>>>>  net/netlabel/netlabel_user.c |  9 +--------
>>>>  3 files changed, 29 insertions(+), 15 deletions(-)
>>> Other than moving to the subject count supplied by the LSM
>>> initialization patchset previously mentioned, this looks fine to me.
>> I'm perfectly willing to switch once the LSM initialization patch set
>> moves past RFC.
> It's obviously your choice as to if/when you switch, but I'm trying to
> let you know that acceptance into the LSM tree is going to be
> dependent on that switch happening.

Not a problem. Obviously, I'd prefer this patch going in before the
LSM initialization work, but it is your call.

> The initialization patchset is still very much alive, and the next
> revision will not be an RFC.  I'm simply waiting on some additional
> LSM specific reviews before posting the next revision so as to not
> burn out people from looking at multiple iterations.  I've been told
> privately by at least one LSM maintainer that reviewing the changes in
> their code is on their todo list, but they have been slammed with
> other work at their job and haven't had the time to look at that
> patchset yet.  I realize you don't have those issues anymore, but I
> suspect you are still sympathetic to those problems.

Of course. Waiting on reviews can be frustrating.

> If you're really anxious to continue work on this RIGHT NOW, you can
> simply base your patchset on top of the initialization patchset.  Just
> make sure you mention in the cover letter what you are using as a base
> for the patchset.

As I don't anticipate serious changes to your patch set this makes sense.

> If that still doesn't offer any satisfaction, you can always
> incorporate the feedback that I made in v2 that was ignored in your v3
> posting :-P

Yeah, oops on that.