[RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Justin Suess]

On 1/1/26 17:19, Tingmao Wang wrote:
> On 1/1/26 22:11, Demi Marie Obenour wrote:
>> On 1/1/26 17:07, Tingmao Wang wrote:
>>
>> (snip)
>>
>>> Looking at this I guess it might also make sense for the kernel side to
>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
>>>
>>> Also, for the sandboxer logic, maybe a better way would be having
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
>>> then another if(!S_ISSOCK) below this that will clear out
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
>> A process might legitimately need to connect to a socket that doesn't
>> exist at the time it sandboxes itself.  Therefore, I think it makes
>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
>> directory.  This matches the flexibility mount namespaces can achieve.
> Right, I forgot about the fact that we also need it on dirs, apologies.
>
> (But maybe it might still make sense to not allow this on files which are
> neither a socket or a dir? (If the file later gets removed and recreated
> as a socket, the rule would not apply retroactively anyway due to being
> tied to the inode.))
How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.

Sockets seem like a similar case where the operation is only valid for a subset of file types.

I think we should mirror the existing behavior is for consistency.

Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).

Justin