netdev - Re: [PATCH v2 1/5] lsm: Add hook unix_path

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: <4c3956c2-4133-46bb-9ee5-4abf9bf7fff8@gmail.com>
Date: Thu, 15 Jan 2026 16:24:48 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: Günther Noack <gnoack3000@...il.com>,
 Paul Moore <paul@...l-moore.com>, Christian Brauner <brauner@...nel.org>,
 Justin Suess <utilityemal77@...il.com>
Cc: Mickaël Salaün <mic@...ikod.net>,
 James Morris <jmorris@...ei.org>, "Serge E . Hallyn" <serge@...lyn.com>,
 linux-security-module@...r.kernel.org, Tingmao Wang <m@...wtm.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, 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>
Subject: Re: [PATCH v2 1/5] lsm: Add hook unix_path_connect

On 1/15/26 05:10, Günther Noack wrote:
> On Tue, Jan 13, 2026 at 06:27:15PM -0500, Paul Moore wrote:
>> On Tue, Jan 13, 2026 at 4:34 AM Christian Brauner <brauner@...nel.org> wrote:
>>> On Sat, Jan 10, 2026 at 03:32:57PM +0100, Günther Noack wrote:
>>>> From: Justin Suess <utilityemal77@...il.com>
>>>>
>>>> Adds an LSM hook unix_path_connect.
>>>>
>>>> This hook is called to check the path of a named unix socket before a
>>>> connection is initiated.
>>>>
>>>> Cc: Günther Noack <gnoack3000@...il.com>
>>>> Signed-off-by: Justin Suess <utilityemal77@...il.com>
>>>> ---
>>>>  include/linux/lsm_hook_defs.h |  4 ++++
>>>>  include/linux/security.h      | 11 +++++++++++
>>>>  net/unix/af_unix.c            |  9 +++++++++
>>>>  security/security.c           | 20 ++++++++++++++++++++
>>>>  4 files changed, 44 insertions(+)
>>
>> ...

...

> * Some properties of the resolved socket are still observable to
>   userspace:
> 
>   When we only pass the path to a later LSM hook, there are a variety
>   of additional error case checks in af_unix.c which are based on the
>   "other" socket which we looked up through the path.  Examples:
> 
>   * was other shutdown(2)? (ECONNREFUSED on connect or EPIPE on dgram_sendmsg)
>   * does other support SO_PASSRIGHTS (fd passing)? (EPERM on dgram_sendmsg)
>   * would sendmsg pass sk_filter() (on dgram_sendmsg)
> 
>   For a LSM policy that is supposed to restrict the resolution of a
>   UNIX socket by path, I would not expect such properties of the
>   resolved socket to be observable?
> 
>   (And we also can't fix this up in the LSM by returning a matching
>   error code, because at least unix_dgram_sendmsg() returns multiple
>   different error codes in these error cases.)
> 
>   I would prefer if the correctness of our LSM did not depend on
>   keeping track of the error scenarios in af_unix.c.  This seems
>   brittle.

Indeed so.

> Overall, I am not convinced that using pre-existing hooks is the right
> way and I would prefer the approach where we have a more dedicated LSM
> hook for the path lookup.
> 
> Does that seem reasonable?  Let me know what you think.
> 
> –Günther

Having a dedicated LSM hook for all path lookups is definitely my
preferred approach.  Could this allow limiting directory traversal
as well?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)