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: <CAHC9VhQ234xihpndTs4e5ToNJ3tGCsP7AVtXuz8GajG-_jn3Ow@mail.gmail.com>
Date: Wed, 7 Jan 2026 16:43:33 -0500
From: Paul Moore <paul@...l-moore.com>
To: Justin Suess <utilityemal77@...il.com>
Cc: gnoack3000@...il.com, gnoack@...gle.com, horms@...nel.org, 
	jmorris@...ei.org, kuniyu@...gle.com, linux-security-module@...r.kernel.org, 
	m@...wtm.org, mic@...ikod.net, netdev@...r.kernel.org, serge@...lyn.com
Subject: Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect

On Thu, Jan 1, 2026 at 2:45 PM Justin Suess <utilityemal77@...il.com> wrote:
> On 1/1/26 07:13, Günther Noack wrote:
> > On Wed, Dec 31, 2025 at 04:33:14PM -0500, Justin Suess wrote:
> >> 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.
> >>
> >> Signed-off-by: Justin Suess <utilityemal77@...il.com>
> >> Cc: Günther Noack <gnoack3000@...il.com>
> >> ---
> >>  include/linux/lsm_hook_defs.h |  1 +
> >>  include/linux/security.h      |  6 ++++++
> >>  net/unix/af_unix.c            |  8 ++++++++
> >>  security/security.c           | 16 ++++++++++++++++
> >>  4 files changed, 31 insertions(+)

...

> >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> >> index 55cdebfa0da0..af1a6083a69b 100644
> >> --- a/net/unix/af_unix.c
> >> +++ b/net/unix/af_unix.c
> >> @@ -1226,6 +1226,14 @@ static struct sock *unix_find_bsd(struct sockaddr_un *sunaddr, int addr_len,
> >>      if (!S_ISSOCK(inode->i_mode))
> >>              goto path_put;
> >>
> >> +    /*
> >> +     * We call the hook because we know that the inode is a socket
> >> +     * and we hold a valid reference to it via the path.
> >> +     */
> >> +    err = security_unix_path_connect(&path);
> >> +    if (err)
> >> +            goto path_put;
> >
> > In this place, the hook call is done also for the coredump socket.
> >
> > The coredump socket is a system-wide setting, and it feels weird to me
> > that unprivileged processes should be able to inhibit that connection?
>
> No I don't think they should be able to. Does this look better?

Expect more comments on this patch, but this is important enough that
I wanted to reply separately.

As a reminder, we do have guidance regarding the addition of new LSM
hooks, there is a pointer to the document in MAINTAINERS, but here is
a direct link to the relevant section:

https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks

The guidance has three bullet points, the first, and perhaps most
important, states:

  "Hooks should be designed to be LSM agnostic. While it is possible
   that only one LSM might implement the hook at the time of submission,
   the hook's behavior should be generic enough that other LSMs could
   provide a meaningful implementation."

This is one of the reasons why we generally don't make the LSM hook
calls conditional on kernel state outside of the LSM, e.g.
SOCK_COREDUMP.  While Landlock may not want to implement any access
controls on a SOCK_COREDUMP socket, it's entirely possible that
another LSM which doesn't have untrusted processes defining security
policy may want to use this as a point of access control or
visibility/auditing.  Further, I think it would be a good idea to also
pass the @type and @flags parameter to the hook; at the very least
Landlock would need the flags parameter to check for SOCK_COREDUMP.

-- 
paul-moore.com