On Thu, Jul 10, 2025 at 05:00:18PM +0000, Song Liu wrote: > > > > On Jul 10, 2025, at 4:46 AM, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > [...] > > >> Right now, we have security_sb_mount and security_move_mount, for > >> syscall “mount” and “move_mount” respectively. This is confusing > >> because we can also do move mount with syscall “mount”. How about > >> we create 5 different security hooks: > >> > >> security_bind_mount > >> security_new_mount > >> security_reconfigure_mount > >> security_remount > >> security_change_type_mount > >> > >> and remove security_sb_mount. After this, we will have 6 hooks for > >> each type of mount (the 5 above plus security_move_mount). > > > > I've multiple times pointed out that the current mount security hooks > > aren't working and basically everything in the new mount api is > > unsupervised from an LSM perspective. > > To make sure I understand the comment. By “new mount api”, do you mean > the code path under do_new_mount()? fsopen() fsconfig() fsmount() open_tree() open_tree_attr() move_mount() statmount() listmount() I think that's all. > > > My recommendation is make a list of all the currently supported > > security_*() hooks in the mount code (I certainly don't have them in my > > head). Figure out what each of them allow to mediate effectively and how > > the callchains are related. > > > > Then make a proposal how to replace them with something that a) doesn't > > cause regressions which is probably something that the LSMs care about > > and b) that covers the new mount API sufficiently to be properly > > mediated. > > > > I'll happily review proposals. Fwiw, I'm pretty sure that this is > > something that Mickael is interested in as well. > > So we will consider a proper redesign of LSM hooks for mount syscalls, > but we do not want incremental improvements like this one. Do I get > the direction right? If incremental is workable then I think so yes. But it would be great to get a consistent picture of what people want/need.
