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

[Mickaël Salaün]

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:
> > On Thu, Jan 01, 2026 at 02:40:57PM +0100, Günther Noack wrote:
> > > ## 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]).
> > > 
> > > These patches are built on Justin Suess's patch which adds the LSM
> > > hook:
> > > https://lore.kernel.org/all/20251231213314.2979118-1-utilityemal77@gmail.com/
> > 
> > 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

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

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