netdev - Re: [RFC PATCH 0/1] 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: <CAAVpQUB6gnfovRZAg_BfVKPuS868dFj7HxthbxRL-nZvcsOzCg@mail.gmail.com>
Date: Tue, 6 Jan 2026 23:33:32 -0800
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Günther Noack <gnoack@...gle.com>
Cc: Justin Suess <utilityemal77@...il.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E . Hallyn" <serge@...lyn.com>, Simon Horman <horms@...nel.org>, 
	Mickaël Salaün <mic@...ikod.net>, 
	linux-security-module@...r.kernel.org, Tingmao Wang <m@...wtm.org>, 
	netdev@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, 
	Christian Brauner <brauner@...nel.org>
Subject: Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect

+VFS maintainers

On Mon, Jan 5, 2026 at 3:04 AM Günther Noack <gnoack@...gle.com> wrote:
>
> Hello!
>
> On Sun, Jan 04, 2026 at 11:46:46PM -0800, Kuniyuki Iwashima wrote:
> > On Wed, Dec 31, 2025 at 1:33 PM Justin Suess <utilityemal77@...il.com> wrote:
> > > Motivation
> > > ---
> > >
> > > For AF_UNIX sockets bound to a filesystem path (aka named sockets), one
> > > identifying object from a policy perspective is the path passed to
> > > connect(2). However, this operation currently restricts LSMs that rely
> > > on VFS-based mediation, because the pathname resolved during connect()
> > > is not preserved in a form visible to existing hooks before connection
> > > establishment.
> >
> > Why can't LSM use unix_sk(other)->path in security_unix_stream_connect()
> > and security_unix_may_send() ?
>
> Thanks for bringing it up!
>
> That path is set by the process that acts as the listening side for
> the socket.  The listening and the connecting process might not live
> in the same mount namespace, and in that case, it would not match the
> path which is passed by the client in the struct sockaddr_un.

Thanks for the explanation !

So basically what you need is resolving unix_sk(sk)->addr.name
by kern_path() and comparing its d_backing_inode(path.dentry)
with d_backing_inode (unix_sk(sk)->path.dendtry).

If the new hook is only used by Landlock, I'd prefer doing that on
the existing connect() hooks.


>
> For more details, see
> https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
> and
> https://github.com/landlock-lsm/linux/issues/36#issuecomment-2950632277
>
> Justin: Maybe we could add that reasoning to the cover letter in the
> next version of the patch?
>
> –Günther