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

["Günther Noack" <gnoack3000@gmail.com>]

Thanks for the review!

On Mon, Jan 12, 2026 at 05:08:02PM +0100, Mickaël Salaün wrote:
> On Sat, Jan 10, 2026 at 03:32:55PM +0100, Günther Noack wrote:
> > ## 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.


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

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


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


> 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