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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhTbrk_XovghLTtqPUv3br9aJbn2YcnFyn3uugTUKAHNFw@mail.gmail.com>
Date: Wed, 30 Apr 2025 14:51:03 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.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
Subject: Re: [PATCH v3 4/5] Audit: multiple subject lsm values for netlabel

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.

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.

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.

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

-- 
paul-moore.com