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 (?), 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. Hope this information is useful. 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/
