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: <CAHC9VhQF26sVYoKxZ_7x2nL1HxuK0zeH013e8ugigz9B+Kpkjg@mail.gmail.com>
Date: Wed, 7 Jan 2026 16:54:02 -0500
From: Paul Moore <paul@...l-moore.com>
To: Justin Suess <utilityemal77@...il.com>
Cc: James Morris <jmorris@...ei.org>, "Serge E . Hallyn" <serge@...lyn.com>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, Simon Horman <horms@...nel.org>, 
	Mickaël Salaün <mic@...ikod.net>, 
	Günther Noack <gnoack@...gle.com>, 
	linux-security-module@...r.kernel.org, Tingmao Wang <m@...wtm.org>, 
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect

On Wed, Dec 31, 2025 at 4:33 PM Justin Suess <utilityemal77@...il.com> wrote:
>
> Hi,
>
> This patch introduces a new LSM hook unix_path_connect.
>
> The idea for this patch and the hook came from Günther Noack, who
> is cc'd. Much credit to him for the idea and discussion.
>
> This patch is based on the lsm next branch.
>
> 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. As a result, LSMs such as Landlock cannot currently
> restrict connections to named UNIX domain sockets by their VFS path.
>
> This gap has been discussed previously (e.g. in the context of Landlock's
> path-based access controls). [1] [2]
>
> I've cc'd the netdev folks as well on this, as the placement of this hook is
> important and in a core unix socket function.
>
> Design Choices
> ---
>
> The hook is called in net/unix/af_unix.c in the function unix_find_bsd().
>
> The hook takes a single parameter, a const struct path* to the named unix
> socket to which the connection is being established.
>
> The hook takes place after normal permissions checks, and after the
> inode is determined to be a socket. It however, takes place before
> the socket is actually connected to.
>
> If the hook returns non-zero it will do a put on the path, and return.
>
> References
> ---
>
> [1]: https://github.com/landlock-lsm/linux/issues/36#issue-2354007438
> [2]: https://lore.kernel.org/linux-security-module/cover.1767115163.git.m@maowtm.org/
>
> Kind Regards,
> Justin Suess
>
> Justin Suess (1):
>   lsm: Add hook unix_path_connect
>
>  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(+)

A couple of things related to the documentation aspects of this patch.
First, since this is just a single patch, and will need to be part of
a larger patchset to gain acceptance[1], please skip the cover letter
and ensure that the patch's description contains all the important
information.  Similarly, while it is fine to include references to
other sources of discussion in the patch's description, the links
should not replace a proper explanation of the patch.  Whenever you
are writing a patch description, imagine yourself ten years in the
future, on a plane with no/terrible network access, trying to debug an
issue and all you have for historical information is the git log.  I
promise you, it's not as outlandish as it might seem ;)

[1] See my other reply regarding new LSM hook guidance; this patch
will need to be part of a larger patchset that actually makes use of
this hook.

-- 
paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ