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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2393 bytes --]

On 1/2/26 05:50, Günther Noack wrote:
> On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
>> On 1/2/26 05:16, Günther Noack wrote:
>>> On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
>>>> On 1/1/26 17:34, Tingmao Wang wrote:
>>>>> On 1/1/26 22:14, Demi Marie Obenour wrote:
>>>>>> [...]
>>>>>> Does this leave directory traversal as the only missing Landlock
>>>>>> filesystem access control?  Ideally Landlock could provide the same
>>>>>> isolation from the filesystem that mount namespaces do.
>>>>>
>>>>> I think that level of isolation would require path walk control - see:
>>>>> https://github.com/landlock-lsm/linux/issues/9
>>>>>
>>>>> (Landlock also doesn't currently control some metadata operations - see
>>>>> the warning at the end of the "Filesystem flags" section in [1])
>>>>>
>>>>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
>>>>
>>>> Could this replace all of the existing hooks?
>>>
>>> If you do not need to distinguish between the different operations
>>> which Landlock offers access rights for, but you only want to limit
>>> the visibility of directory hierarchies in the file system, then yes,
>>> the path walk control described in issue 9 would be sufficient and a
>>> more complete control.
>>>
>>> The path walk control is probably among the more difficult Landlock
>>> feature requests.  A simple implementation would be easy to implement
>>> technically, but it also requires a new LSM hook which will have to
>>> get called *during* path lookup, and we'd have to make sure that the
>>> performance impact stays in check.  Path lookup is after all a very
>>> central facility in a OS kernel.
>>
>> What about instead using the inode-based hooks for directory searching?
>> SELinux can already restrict that.
> 
> Oh, thanks, good pointer!  I was under the impression that this didn't
> exist yet -- I assume you are referring to the
> security_inode_follow_link() hook, which is already happening during
> path resolution?

I'm not familiar with existing LSM hooks, but I do know that SELinux
enforces checks on searching and reading directories and symlinks.

> I take it back then. :) If there is prior art, implementing this might
> be more feasible than I thought.

I think so too!
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]