[RFC PATCH 0/9] Landlock supervise: a mechanism for interactive permission requests

[Mickaël Salaün]

On Thu, Mar 06, 2025 at 06:07:35PM +0100, Amir Goldstein wrote:
> On Thu, Mar 6, 2025 at 3:57 AM Tingmao Wang <m at maowtm.org> wrote:
> >
> > On 3/4/25 19:48, Mickaël Salaün wrote:
> >
> > > Thanks for this RFC, this is very promising!
> >
> > Hi Mickaël - thanks for the prompt review and for your support! I have
> > read your replies and have some thoughts already, but I kept getting
> > distracted by other stuff and so haven't had much chance to express
> > them.  I will address some first today and some more over the weekend.
> >
> > > Another interesting use case is to trace programs and get an
> > > unprivileged "permissive" mode to quickly create sandbox policies.
> >
> > Yes that would also be a good use. I thought of this initially but was
> > thinking "I guess you can always do that with audit" but if we have
> > landlock supervise maybe that would be an easier thing for tools to
> > build upon...?
> >
> > > As discussed, I was thinking about whether or not it would be possible
> > > to use the fanotify interface (e.g. fanotify_init(), fanotify FD...),
> > > but looking at your code, I think it would mostly increase complexity.
> > > There are also the issue with the Landlock semantic (e.g. access rights)
> > > which does not map 1:1 to the fanotify one.  A last thing is that
> > > fanotify is deeply tied to the VFS.  So, unless someone has a better
> > > idea, let's continue with your approach.
> >
> > That sounds sensible - I will keep going with the current direction of a
> > landlock-specific uapi. (happy to revisit should other people have
> > suggestions)
> >
> 
> w.r.t sharing infrastructure with fanotify, I only looked briefly at
> your patches
> and I have only a vague familiarity with landlock, so I cannot yet form an
> opinion whether this is a good idea, but I wanted to give you a few more
> data points about fanotify that seem relevant.
> 
> 1. There is already some intersection of fanotify and audit lsm via the
> fanotify_response_info_audit_rule extension for permission
> events, so it's kind of a precedent of using fanotify to aid an lsm
> 
> 2. See this fan_pre_modify-wip branch [1] and specifically commit
>   "fanotify: introduce directory entry pre-modify permission events"
> I do have an intention to add create/delete/rename permission events.
> Note that the new fsnotify hooks are added in to do_ vfs helpers, not very
> far from the security_path_ lsm hooks, but not exactly in the same place
> because we want to fsnotify hooks to be before taking vfs locks, to allow
> listener to write to filesystem from event context.
> There are different semantics than just ALLOW/DENY that you need,
> therefore, only if we move the security_path_ hooks outside the
> vfs locks, our use cases could use the same hooks
> 
> 3. There is a recent attempt to add BPF filter to fanotify [2]
> which is driven among other things from the long standing requirement
> to add subtree filtering to fanotify watches.
> The challenge with all the attempt to implement a subtree filter so far,
> is that adding vfs performance overhead for all the users in the system
> is unacceptable.
> 
> IIUC, landlock rule set can already express a subtree filter (?),

Yes, Landlock uses a set of inode tags and a path walk to identify
hierarchies.

> so it is intriguing to know if there is room for some integration on this
> aspect, but my guess is that landlock mostly uses subtree filter
> after filtering by specific pids (?), so it can avoid the performance
> overhead of a subtree filter on most of the users in the system.

Landlock domains are indeed enforced for a set of specific tasks.

> 
> Hope this information is useful.

Yes, thanks for the explanations.  We should definitely take inspiration
from fanotify but I don't think it would be a good fit for Landlock: the
semantic of access rights is (and will) be different, and more
importantly it is not only to supervise filesystem accesses.

> 
> Thanks,
> Amir.
> 
> [1] https://github.com/amir73il/linux/commits/fan_pre_modify-wip/
> [2] https://lore.kernel.org/linux-fsdevel/20241122225958.1775625-1-song@kernel.org/