Re: [PATCH v2 0/5] landlock: Pathname-based UNIX connect() control

["Mickaël Salaün" <mic@digikod.net>]

On Sat, Jan 10, 2026 at 03:32:55PM +0100, Günther Noack wrote:
> Hello!
> 
> This patch set introduces a filesystem-based Landlock restriction
> mechanism for connecting to UNIX domain sockets (or addressing them
> with sendmsg(2)).  It introduces a file system access right for each
> type of UNIX domain socket:
> 
>  * LANDLOCK_ACCESS_FS_RESOLVE_UNIX_STREAM
>  * LANDLOCK_ACCESS_FS_RESOLVE_UNIX_DGRAM
>  * LANDLOCK_ACCESS_FS_RESOLVE_UNIX_SEQPACKET
> 
> For the connection-oriented SOCK_STREAM and SOCK_SEQPACKET type
> sockets, the access right makes the connect(2) operation fail with
> EACCES, if denied.
> 
> SOCK_DGRAM-type UNIX sockets can be used both with connect(2), or by
> passing an explicit recipient address with every sendmsg(2)
> invocation.  In the latter case, the Landlock check is done when an
> explicit recipient address is passed to sendmsg(2) and can make
> sendmsg(2) return EACCES.  When UNIX datagram sockets are connected
> with connect(2), a fixed recipient address is associated with the
> socket and the check happens during connect(2) and may return EACCES.
> 
> ## Motivation
> 
> Currently, landlocked processes can connect() to named UNIX sockets
> through the BSD socket API described in unix(7), by invoking socket(2)
> followed by connect(2) with a suitable struct sockname_un holding the
> socket's filename.  This can come as a surprise for users (e.g. in
> [1]) and it can be used to escape a sandbox when a Unix service offers
> command execution (some scenarios were listed by Tingmao Wang in [2]).
> 
> The original feature request is at [4].
> 
> ## Alternatives and Related Work
> 

> ### Alternative: Use existing LSM hooks
> 
> The existing hooks security_unix_stream_connect(),
> security_unix_may_send() and security_socket_connect() do not give
> access to the resolved file system path.
> 
> Resolving the file system path again within Landlock would in my
> understanding produce a TOCTOU race, so making the decision based on
> the struct sockaddr_un contents is not an option.
> 
> It is tempting to use the struct path that the listening socket is
> bound to, which can be acquired through the existing hooks.
> Unfortunately, the listening socket may have been bound from within a
> different namespace, and it is therefore a path that can not actually
> be referenced by the sandboxed program at the time of constructing the
> Landlock policy.  (More details are on the Github issue at [6] and on
> the LKML at [9]).

Please move (or duplicate) this rationale in the patch dedicated to the
new hook.  It helps patch review (and to understand commits when already
merged).

> 
> ### Related work: Scope Control for Pathname Unix Sockets
> 
> The motivation for this patch is the same as in Tingmao Wang's patch
> set for "scoped" control for pathname Unix sockets [2], originally
> proposed in the Github feature request [5].
> 
> In my reply to this patch set [3], I have discussed the differences
> between these two approaches.  On the related discussions on Github
> [4] and [5], there was consensus that the scope-based control is
> complimentary to the file system based control, but does not replace
> it.  Mickael's opening remark on [5] says:
> 
> > This scoping would be complementary to #36 which would mainly be
> > about allowing a sandboxed process to connect to a more privileged
> > service (identified with a path).
> 
> ## Open questions in V2
> 
> Seeking feedback on:
> 
> - Feedback on the LSM hook name would be appreciated. We realize that
>   not all invocations of the LSM hook are related to connect(2) as the
>   name suggests, but some also happen during sendmsg(2).

Renaming security_unix_path_connect() to security_unix_find() would look
appropriate to me wrt the caller.

> - Feedback on the structuring of the Landlock access rights, splitting
>   them up by socket type.  (Also naming; they are now consistently
>   called "RESOLVE", but could be named "CONNECT" in the stream and
>   seqpacket cases?)

I don't see use cases where differenciating the type of unix socket
would be useful.  LANDLOCK_ACCESS_FS_RESOLVE_UNIX would look good to me.

Tests should still cover all these types though.

What would be the inverse of "resolve" (i.e. to restrict the server
side)?  Would LANDLOCK_ACCESS_FS_MAKE_SOCK be enough?

> 
> ## Credits
> 
> The feature was originally suggested by Jann Horn in [7].
> 
> Tingmao Wang and Demi Marie Obenour have taken the initiative to
> revive this discussion again in [1], [4] and [5] and Tingmao Wang has
> sent the patch set for the scoped access control for pathname Unix
> sockets [2].
> 
> Justin Suess has sent the patch for the LSM hook in [8].
> 
> Ryan Sullivan has started on an initial implementation and has brought
> up relevant discussion points on the Github issue at [4] that lead to
> the current approach.
> 
> [1] https://lore.kernel.org/landlock/515ff0f4-2ab3-46de-8d1e-5c66a93c6ede@gmail.com/
> [2] Tingmao Wang's "Implemnet scope control for pathname Unix sockets"
>     https://lore.kernel.org/all/cover.1767115163.git.m@maowtm.org/
> [3] https://lore.kernel.org/all/20251230.bcae69888454@gnoack.org/
> [4] Github issue for FS-based control for named Unix sockets:
>     https://github.com/landlock-lsm/linux/issues/36
> [5] Github issue for scope-based restriction of named Unix sockets:
>     https://github.com/landlock-lsm/linux/issues/51
> [6] https://github.com/landlock-lsm/linux/issues/36#issuecomment-2950632277
> [7] https://lore.kernel.org/linux-security-module/CAG48ez3NvVnonOqKH4oRwRqbSOLO0p9djBqgvxVwn6gtGQBPcw@mail.gmail.com/
> [8] Patch for the LSM hook:
>     https://lore.kernel.org/all/20251231213314.2979118-1-utilityemal77@gmail.com/
> [9] https://lore.kernel.org/all/20260108.64bd7391e1ae@gnoack.org/
> 
> ---
> 
> ## Older versions of this patch set
> 
> V1: https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
> 
> Changes in V2:
>  * Send Justin Suess's LSM hook patch together with the Landlock
>    implementation
>  * LSM hook: Pass type and flags parameters to the hook, to make the
>    access right more generally usable across LSMs, per suggestion from
>    Paul Moore (Implemented by Justin)
>  * Split the access right into the three types of UNIX domain sockets:
>    SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET.
>  * selftests: More exhaustive tests.
>  * Removed a minor commit from V1 which adds a missing close(fd) to a
>    test (it is already in the mic-next branch)
> 
> Günther Noack (4):
>   landlock: Control pathname UNIX domain socket resolution by path
>   samples/landlock: Add support for named UNIX domain socket
>     restrictions
>   landlock/selftests: Test named UNIX domain socket restrictions
>   landlock: Document FS access rights for pathname UNIX sockets
> 
> Justin Suess (1):
>   lsm: Add hook unix_path_connect
> 
>  Documentation/userspace-api/landlock.rst     |  25 ++-
>  include/linux/lsm_hook_defs.h                |   4 +
>  include/linux/security.h                     |  11 +
>  include/uapi/linux/landlock.h                |  10 +
>  net/unix/af_unix.c                           |   9 +
>  samples/landlock/sandboxer.c                 |  18 +-
>  security/landlock/access.h                   |   2 +-
>  security/landlock/audit.c                    |   6 +
>  security/landlock/fs.c                       |  34 ++-
>  security/landlock/limits.h                   |   2 +-
>  security/landlock/syscalls.c                 |   2 +-
>  security/security.c                          |  20 ++
>  tools/testing/selftests/landlock/base_test.c |   2 +-
>  tools/testing/selftests/landlock/fs_test.c   | 225 +++++++++++++++++--
>  14 files changed, 344 insertions(+), 26 deletions(-)
> 
> -- 
> 2.52.0
> 
>