[PATCH v4 2/6] landlock: Control pathname UNIX domain socket resolution by path

Justin Suess utilityemal77 at gmail.com
Mon Feb 9 13:11:18 UTC 2026


On 2/9/26 05:21, Günther Noack wrote:
> On Mon, Feb 09, 2026 at 12:10:12AM +0100, Günther Noack wrote:
>> +static int hook_unix_find(const struct path *const path, struct sock *other,
>> +			  int flags)
>> +{
>> +	const struct landlock_ruleset *dom_other;
>> +	const struct landlock_cred_security *subject;
>> +	struct layer_access_masks layer_masks;
>> +	struct landlock_request request = {};
>> +	static const struct access_masks fs_resolve_unix = {
>> +		.fs = LANDLOCK_ACCESS_FS_RESOLVE_UNIX,
>> +	};
>> +	int type = other->sk_type;
>> +
>> +	/* Lookup for the purpose of saving coredumps is OK. */
>> +	if (flags & SOCK_COREDUMP)
>> +		return 0;   
if (unlikely(flags & SOCK_COREDUMP))
    return 0;
>> +
>> +	/* Only stream, dgram and seqpacket sockets are restricted. */
>> +	if (type != SOCK_STREAM && type != SOCK_DGRAM && type != SOCK_SEQPACKET)
>> +		return 0;
if (unlikely(type != SOCK_STREAM && type != SOCK_DGRAM && type != SOCK_SEQPACKET))
    return 0;
> FYI: This is a (highly speculative) safeguard, because these three
> socket types are the only ones that exist in AF_UNIX (compare unix(7),
> 2nd paragraph).
>
> In the (highly unlikely) case that someone adds a fourth AF_UNIX
> socket type, this means that Landlock will start permitting
> connections to these sockets unconditionally.
>
> I am unsure whether the safeguard is useful, or whether we should
> rather group that (highly unlikely) future socket type together with
> the existing ones.  *If you have opinions, I'd be interested.*
In that case, a new access right could be added for that new socket type.

So we should only handle the ones we expect for now, and reserve the option for future rights
to expand the capability.
>
> The fact that these are the only existing AF_UNIX socket types is also
> the reason why it does not matter that we are now (in v4) taking the
> type value from the server-side sk instead of the client socket.  The
> check will either way always pass as long as only these three types
> are the only ones.
Last time a new socket type for UDS (seqpacket) was added was 2.6.4.
UDS are also part of POSIX, so they're pretty standardized and not exactly likely to change.

>
> For now (and probably for another few decades :)), as long as these
> are the only AF_UNIX types, it does not make a difference though
> whether the check is there or not.
I think this is the correct choice.
>
> —Günther




More information about the Linux-security-module-archive mailing list