Message-ID: <62eda124-de91-4445-b163-9dfb8039d08c@gmail.com>
Date: Sat, 17 Jan 2026 13:57:20 -0500
From: Justin Suess <utilityemal77@...il.com>
To: Günther Noack <gnoack3000@...il.com>,
 Mickaël Salaün <mic@...ikod.net>
Cc: Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
 "Serge E . Hallyn" <serge@...lyn.com>,
 linux-security-module@...r.kernel.org, Tingmao Wang <m@...wtm.org>,
 Samasth Norway Ananda <samasth.norway.ananda@...cle.com>,
 Matthieu Buffet <matthieu@...fet.re>,
 Mikhail Ivanov <ivanov.mikhail1@...wei-partners.com>,
 konstantin.meskhidze@...wei.com, Demi Marie Obenour <demiobenour@...il.com>,
 Alyssa Ross <hi@...ssa.is>, Jann Horn <jannh@...gle.com>,
 Tahera Fahimi <fahimitahera@...il.com>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v2 0/5] landlock: Pathname-based UNIX connect() control

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:
>> 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.
No problem.

It's quite long, so would it make sense in the notes?
Instead of directly in the commit message?
>
>
>>> ### 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.)
security_unix_find works for me, and seems to better match the hook
location. I'll send an updated commit.
>
>
>>> - 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

Powered by blists - more mailing lists