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

[Mickaël Salaün]

On Fri, Jan 09, 2026 at 04:02:25PM -0500, Demi Marie Obenour wrote:
> On 1/9/26 10:25, Mickaël Salaün wrote:
> > On Fri, Jan 09, 2026 at 06:33:10AM -0500, Demi Marie Obenour wrote:
> >> On 1/8/26 06:14, Mickaël Salaün wrote:
> >>> 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
> >>
> >> Could Landlock use a side table, with the inode's address in memory
> >> as the key?
> > 
> > A struct inode is not enough because we need to resolve a file
> > hierarchy, which is only possible with a struct path.
> 
> Could Landlock "piggyback" on the core kernel's own path resolution,
> updating its state when each hook gets called?

Most of the inode-based hooks are called in places where there is no
path data (in the current context).  We should be very careful with
changes to the VFS wrt performance and complexity.  If you have an idea
of how to do it, I encourage you to test it and send an RFC.