On 1/12/26 15:53, Günther Noack wrote:

Thanks for the review!

On Mon, Jan 12, 2026 at 05:08:02PM +0100, Mickaël Salaün wrote:

quoted

On Sat, Jan 10, 2026 at 03:32:55PM +0100, Günther Noack wrote:

quoted

## 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).

Justin, would you like to look into this?
Please feel free to copy the wording.

No problem.

It's quite long, so would it make sense in the notes?
Instead of directly in the commit message?

quoted

quoted

### 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:

quoted

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.

Justin, this is also on your commit.  (I find security_unix_find() and
security_unix_resolve() equally acceptable options.)

security_unix_find works for me, and seems to better match the hook
location. I'll send an updated commit.

quoted

quoted

- 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.

I did it mostly because it seemed consistent with the TCP and (soon)
UDP controls, which are also controls specific to the socket type and
not just the address family.  But I agree that the granularity is
likely not needed here.  I can change it back for v3 and rename it to
LANDLOCK_ACCESS_FS_RESOLVE_UNIX.

quoted

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

Yes, that would be enough. My reasoning is as follows:

The server-side operation that is related to associating the service
with a given file system name is bind(2), and that is restrictable in
that case using LANDLOCK_ACCESS_FS_MAKE_SOCK.

Also, to my delight (and other than in TCP), listening on an unbound
socket does not work (see unix_listen() in af_unix.c):

  if (!READ_ONCE(u->addr))
  	goto out;	/* No listens on an unbound socket */

(You can get it to "autobind" during an explicit bind() or a connect()
call, but that creates an abstract UNIX address. (Documented in
socket(7) and implemented in unix_autobind() in af_unix.c))


–Günther