On Thu, Mar 06, 2025 at 02:57:13AM +0000, Tingmao Wang 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...? Both approaches are valuable. The supervisor one would be unprivileged, could get access to more information including O_PATH FD's, but it is much slower and relies on user space monitoring code. > > > 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) > > > Android's SDCardFS is another example of such use. > > Interesting - seems like it was deprecated for reasons unrelated to security > though. Yes, Android first used FUSE, then SDCardFS, then FUSE again, but the goal has been the same: https://source.android.com/docs/core/storage/scoped > > > One of the main suggestion would be to align with the audit patch series > > semantic and the defined "blockers": > > https://lore.kernel.org/all/20250131163059.1139617-1-mic@xxxxxxxxxxx/ > > I'll send another series soon. > > I will have a read of the existing audit series - are you planning > significant changes to it in the next one? Not significant changes but still some that hook changes that might require a rebase. I just sent v6, you'll find it applied here: https://web.git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/log/?h=next
