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

[Mickaël Salaün]

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.