[RFC PATCH 0/1] lsm: Add hook unix_path_connect

[Günther Noack]

Thank you for sending this, Justin!

Paul: Could you please have a look at this new LSM hook? -- it extends
the LSM interface and it is an approach that I have suggested in [1].

On Wed, Dec 31, 2025 at 04:33:13PM -0500, Justin Suess 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]

+1

The use case here is that Landlock should be able to restrict
connect() to named Unix sockets and control this based on the natural
identifier for named Unix sockets -- the path of the socket file.

This feature is a useful and necessary addition to Landlock.  The
discussion that Tingmao Wang linked to on her patch also shows that
users are caught by surprise when they find that connecting to UNIX
sockets is not restrictable [2].  Her patch set [3] lists some ways in
which this can be a problem.


I understand that adding LSM hooks might be controversial, but I think
that the alternatives to the new LSM hook are both worse:

* The patch set from Tingmao Wang at [3] is not restricting Unix
  sockets based on path, but on Landlock policy scope (domain).  This
  is useful, but only complementary to a path-based restriction.  If
  be build both features at some point, they'd potentially have
  surprising interactions that make the UAPI more confusing.  (I've
  written more about this at [4])

* We can not use the existing security_socket_connect() hook for this,
  because the resolved struct path has already been discarded by the
  time when security_socket_connect() is called, and looking up the
  struct path again would create a TOCTOU race condition.
    
  The hook is called from the function unix_find_bsd() in the AF_UNIX
  implementation, which looks up the struct path and keeps it
  transiently in order to find the associated listening-side struct
  sock.


Please let us know what you think!

Thanks!
–Günther


[1] https://github.com/landlock-lsm/linux/issues/36#issuecomment-3669080619
[2] https://spectrum-os.org/lists/archives/spectrum-devel/00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com/
[3] https://lore.kernel.org/all/cover.1767115163.git.m@maowtm.org/
[4] https://lore.kernel.org/all/20251230.bcae69888454@gnoack.org/