netdev - Re: [PATCH v3 1/5] lsm: Add hook security_unix

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: <20260205.gah7Dimu1tho@digikod.net>
Date: Thu, 5 Feb 2026 11:36:26 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Günther Noack <gnoack@...gle.com>
Cc: Günther Noack <gnoack3000@...il.com>, 
	Paul Moore <paul@...l-moore.com>, John Johansen <john.johansen@...onical.com>, 
	Tingmao Wang <m@...wtm.org>, James Morris <jmorris@...ei.org>, 
	"Serge E . Hallyn" <serge@...lyn.com>, Justin Suess <utilityemal77@...il.com>, 
	linux-security-module@...r.kernel.org, Samasth Norway Ananda <samasth.norway.ananda@...cle.com>, 
	Matthieu Buffet <matthieu@...fet.re>, Mikhail Ivanov <ivanov.mikhail1@...wei-partners.com>, 
	konstantin.meskhidze@...wei.com, Demi Marie Obenour <demiobenour@...il.com>, 
	Alyssa Ross <hi@...ssa.is>, Jann Horn <jannh@...gle.com>, 
	Tahera Fahimi <fahimitahera@...il.com>, Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v3 1/5] lsm: Add hook security_unix_find

On Wed, Feb 04, 2026 at 11:25:33AM +0100, Günther Noack wrote:
> Hello!
> 
> 
> John:
> 
> Friendly ping; as Paul said in [1], we would appreciate a look from
> the AppArmor side whether this path-based LSM hook makes sense for
> you.

FYI, we plan to merge this patch series with another one where this new
LSM hook will be used as Günther explained:

> 
> 
> Everyone:
> 
> In [2], we are currently discussing how the UNIX restriction feature
> would work in the bigger scheme in Landlock, and the current plan is
> that long-term we would like to support semantics where a UNIX
> connection attempt is allowed if EITHER:
> 
>  (a) the path is allow-listed in the policy, OR
>  (b) the server side we connect to is part of the same Landlock
>      sandbox ("domain")
> 
> 
> With the currently proposed hook, (a) can be checked in the
> security_unix_find() hook, and (b) can be checked in the
> security_hook_socket_connect() hook.  Unfortunately, it also would
> mean that if the (a) check fails, we would have to store that
> information on the side (struct sock LSM blob?), return 0 from (a) and
> then later use that information in hook (b), so that we can check
> whether maybe the second possible condition is met.
> 
> Q: The passing of information across multiple LSM hooks is slightly
> more complicated than I had hoped; is this an approach that is
> recommended?
> 
> Therefore, in [2], Tingmao is suggesting that we change the
> security_unix_find() hook and pass the "other" struct sock instead of
> the type.

This new approach is much more generic and should please any LSM wishing
to use it.

> 
> There is obviously a balance between hooks that are very generic and
> usable across multiple LSMs and hooks that are convenient to use for
> every LSM.  
> 
> Paul:
> 
> You have previously said that you would like hooks to be generic and
> ideally reflect the arguments of the same function that they are
> called from [3].
> 
> Q: Would it be acceptable to change the hook arguments, if we can then
> avoid passing additional data between hooks through that side-storage?
> You can see Tingmao's proposal for that in [2].  TL;DR: It moves the
> call to security_unix_find() just after the place where the sk
> variable ("other"-side socket) is looked up and then calls the hook
> with the sk as argument instead of with the type.  That way, we can do
> both check (a) and (b) from above in the same hook and do not need to
> store data on the side.  Is that an acceptable trade-off for the LSM
> interface?

I think it's a good interface because it let any LSM check both the
resolved path and the resolved socket (without race condition), which
makes sense and align with most other hooks.

> 
> Thanks,
> —Günther
> 
> [1] https://lore.kernel.org/all/CAHC9VhQZ_J9316Us0squV_f-MjYXPcex34BnJ14vEBxS9Jyjbg@mail.gmail.com/
> [2] https://lore.kernel.org/all/e6b6b069-384c-4c45-a56b-fa54b26bc72a@maowtm.org/
> [3] https://lore.kernel.org/all/CAHC9VhQ234xihpndTs4e5ToNJ3tGCsP7AVtXuz8GajG-_jn3Ow@mail.gmail.com/
>