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

[Mickaël Salaün]

On Fri, Jan 02, 2026 at 01:37:14PM -0500, Demi Marie Obenour wrote:
> 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.

SELinux uses inode-based hooks, which is not (directly) possible for
Landlock because it is an unprivileged access control, which means it
cannot rely on extended file attributes to define a security policy.

See https://github.com/landlock-lsm/linux/issues/9

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