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@xxxxxxxxxx> 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@xxxxxxxxxx/
