> 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()? > 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? Thanks, Song
