On Jul 10, 2025, at 4:46 AM, Christian Brauner [off-list ref] wrote:

[...]

quoted

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