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

[Günther Noack]

On Fri, Jan 09, 2026 at 04:20:49PM +0100, Mickaël Salaün wrote:
> On Fri, Jan 09, 2026 at 03:41:33PM +0100, Günther Noack wrote:
> > On Fri, Jan 09, 2026 at 11:37:12AM +0100, Mickaël Salaün wrote:
> > > As Kuniyuki pointed out [1], we should handle both connect and send.
> > > This would be similar to the scoped restriction from Tingmao.  I guess
> > > we'll need a similar hook for the send operation.  Because there is no
> > > need to differenciate between connected and disconnected unix socket in
> > > a security policy, we should have one access right for both.  Any
> > > proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?
> > > 
> > > [1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/
> > 
> > Ah, thanks for pointing it out.
> > 
> > The restriction as implemented in this patch set already solves this
> > for all the three cases where a Unix socket file is looked up.  I
> > believe that it is happening in all the right times (everytime when
> > the lookup has to happen).
> > 
> > The cases where the restriction applies are the following:
> > 
> > * unix_stream_connect - when calling connect() on a stream socket
> > * unix_dgram_connect - when calling connect() on a dgram socket
> > * unix_dgram_sendmsg - when calling sendmsg() on a dgram socket
> >                        (per-message lookup only)
> > 
> > You can find the code locations by looking for the call to
> > unix_find_other() in af_unix.c.  (That function invokes either
> > unix_find_bsd() or the lookup for abstract Unix sockets.)
> > 
> > In the unix_dgram_sendmsg() case, the lookup is only performed if an
> > explicit sockaddr_un was provided together with the arguments to the
> > sendmsg().  (And sendto(2) also uses the same code path as
> > sendmsg(2).)
> 
> Great

FYI, V2 splits the access rights for the three UNIX access types
SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET.

FYI, I double checked that the logic extends cleanly to the
SOCK_SEQPACKET case as well: SOCK_SEQPACKET is implemented as a thin
layer above the existing hooks for SOCK_STREAM and SOCK_DGRAM - it
does connect(2) with the SOCK_STREAM implementation, and it does
sendmsg(2) with the SOCK_DGRAM implementation, but in the sendmsg(2)
case it removes any explicitly passed recipient addresses beforehand.
(See "unix_seqpacket_ops" in net/unix/af_unix.c) So as far as the UNIX
path lookup hook is concerned, SOCK_SEQPACKET behaves like
SOCK_STREAM, and only invokes the hook during connect(2).


> > It is true that the current name for the access right is slightly
> > misleading.  How about LANDLOCK_ACCESS_FS_UNIX_SEND?  (Like
> > "transmit", but a bit closer to the naming of the sendmsg(2)
> > networking API?)
> 
> We should try to keep the access right naming consistent:
> LANDLOCK_ACCESS_FS_<VERB>[_NOUN]
> 
> What about USE_UNIX, or FIND_UNIX (closer to the kernel function), or
> RESOLVE_UNIX?  It should be clear with the name that it is not about
> listening nor receiving from a process outside of the sandbox (which
> should have its own access right BTW).

Thanks, changed in V2 to say RESOLVE_UNIX, and also split up the
access rights for the three UNIX socket types.

(For reference, the path_resolution(7) man page [1] also uses the verb
"resolve". I think both "resolve" and "lookup" are used exchangeably
for paths.)

[1] https://man7.org/linux/man-pages/man7/path_resolution.7.html

> > (I guess the other alternative would be to wire the socket type
> > information through to the unix_find_bsd() function and pass it
> > through. Would require a small change to the af_unix.c implementation,
> > but then we could tell apart LANDLOCK_ACCESS_FS_UNIX_STREAM_CONNECT
> > and LANDLOCK_ACCESS_FS_UNIX_DGRAM_SEND). WDYT?
> 
> I think the hook should have the same arguments as unix_find_bsd()'s
> ones.  This gives the full context of the call.

You are right, I had not recalled that the socket type information
already gets passed to unix_find_bsd() - it required not much
additional wiring at all, in the end. 👍

–Günther