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

[Mickaël Salaün]

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@digikod.net/
> > 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