[PATCH v2 0/6] Landlock: Implement scope control for pathname Unix sockets

[Günther Noack]

Hello!

Thanks for sending this patch!

On Tue, Dec 30, 2025 at 05:20:18PM +0000, Tingmao Wang wrote:
> Changes in v2:
>   Fix grammar in doc, rebased on mic/next, and extracted common code from
>   hook_unix_stream_connect and hook_unix_may_send into a separate
>   function.
> 
> The rest is the same as the v1 cover letter:
> 
> This patch series extend the existing abstract Unix socket scoping to
> pathname (i.e. normal file-based) sockets as well, by adding a new scope
> bit LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET that works the same as
> LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET, except that restricts pathname Unix
> sockets.  This means that a sandboxed process with this scope enabled will
> not be able to connect to Unix sockets created outside the sandbox via the
> filesystem.
> 
> There is a future plan [1] for allowing specific sockets based on FS
> hierarchy, but this series is only determining access based on domain
> parent-child relationship.  There is currently no way to allow specific
> (outside the Landlock domain) Unix sockets, and none of the existing
> Landlock filesystem controls apply to socket connect().
> 
> With this series, we can now properly protect against things like the the
> following while only relying on Landlock:
> 
>     (running under tmux)
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb ~# LL_FS_RO=/ LL_FS_RW= ./sandboxer bash
>     Executing the sandboxed command...
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
>     cat: /tmp/hi: No such file or directory
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# tmux new-window 'echo hi > /tmp/hi'
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
>     hi
> 
> The above but with Unix socket scoping enabled (both pathname and abstract
> sockets) - the sandboxed shell can now no longer talk to tmux due to the
> socket being created from outside the Landlock sandbox:
> 
>     (running under tmux)
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb ~# LL_FS_RO=/ LL_FS_RW= LL_SCOPED=u:a ./sandboxer bash
>     Executing the sandboxed command...
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
>     cat: /tmp/hi: No such file or directory
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# tmux new-window 'echo hi > /tmp/hi'
>     error connecting to /tmp/tmux-0/default (Operation not permitted)
>     root at 6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
>     cat: /tmp/hi: No such file or directory
> 
> Tmux is just one example.  In a standard systemd session, `systemd-run
> --user` can also be used (--user will run the command in the user's
> session, without requiring any root privileges), and likely a lot more if
> running in a desktop environment with many popular applications.  This
> change therefore makes it possible to create sandboxes without relying on
> additional mechanisms like seccomp to protect against such issues.
> 
> These kind of issues was originally discussed on here (I took the idea for
> systemd-run from Demi):
> https://spectrum-os.org/lists/archives/spectrum-devel/00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com/

What is unclear to me from the examples and the description is: Why is
the boundary between allowed and denied connection targets drawn at
the border of the Landlock domain (the "scope") and why don't we solve
this with the file-system-based approach described in [1]?

**Do we have existing use cases where a service is both offered and
connected to all from within the same Landlock domain, and where the
process enforcing the policy does not control the child process enough
so that it would be possible to allow-list it with a
LANDLOCK_ACCESS_FS_CONNECT_UNIX rule?**

If we do not have such a use case, it seems that the planned FS-based
control mechanism from [1] would do the same job?  Long term, we might
be better off if we only have only one control -- as we have discussed
in [2], having two of these might mean that they interact in
unconventional and possibly confusing ways.

Apart from that, there are some other weaker hints that make me
slightly critical of this patch set:

* We discussed the idea that a FS-based path_beneath rule would act
  implicitly also as an exception for
  LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET, in [2] - one possible way to
  interpret this is that the gravity of the system's logic pulls us
  back towards a FS-based control, and we would have to swim less
  against the stream if we integrated the Unix connect() control in
  that way?

* I am struggling to convince myself that we can tell users to
  restrict LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET as a default, as we are
  currently doing it with the other "scoped" and file system controls.
  (The scoped signals are OK because killing out-of-domain processes
  is clearly bad.  The scoped abstract sockets are usually OK because
  most processes do not need that feature.)

  But there are legitimate Unix services that are still needed by
  unprivileged processes and which are designed to be safe to use.
  For instance, systemd exposes a user database lookup service over
  varlink [3], which can be accessed from arbitrary glibc programs
  through a NSS module.  Using this is incompatible with
  LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET as long as we do not have the
  FS-based control and the surprising implicit permission through a
  path_beneath rule as discussed in [2].

  (Another example is the X11 socket, to which the same reasoning
  should apply, I think, and which is also used by a large number of
  programs.)

I agree that the bug [1] has been asleep for a bit too long, and we
should probably pick this up soon.  As we have not heard back from
Ryan after our last inquiry, IMHO I think it would be fair to take it
over.

Apologies for the difficult feedback - I do not mean to get in the way
of your enthusiasm here, but I would like to make sure that we don't
implement this as a stop-gap measure just because the other bug [1]
seemed more difficult and/or stuck in a github issue interaction.
Let's rather unblock that bug, if that is the case. :)

As usual, I fully acknowledge that I might well be wrong and might
have missed some of the underlying reasons, in which case I will
happily be corrected and change my mind. :)

[1] https://github.com/landlock-lsm/linux/issues/36
[2] https://github.com/landlock-lsm/linux/issues/36#issuecomment-3699749541
[3] https://systemd.io/USER_GROUP_API/

Have a good start into the new year!
–Günther