Re: [RFC] vfs: security: Parse dev_name before calling security_sb_mount

[Christian Brauner <brauner@kernel.org>]

On Wed, Jul 09, 2025 at 05:06:36PM +0000, Song Liu wrote:
> Hi Al and Paul, 
> 
> Thanks for your comments!
> 
> > On Jul 9, 2025, at 8:19 AM, Paul Moore <paul@paul-moore.com> wrote:
> > 
> > On Wed, Jul 9, 2025 at 6:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >> On Tue, Jul 08, 2025 at 04:05:04PM -0700, Song Liu wrote:
> >>> security_sb_mount handles multiple types of mounts: new mount, bind
> >>> mount, etc. When parameter dev_name is a path, it need to be parsed
> >>> with kern_path.
> > 
> > ...
> > 
> >> security_sb_mount() is and had always been a mind-boggling trash of an API.
> >> 
> >> It makes no sense in terms of operations being requested.  And any questions
> >> regarding its semantics had been consistently met with blanket "piss off,
> >> LSM gets to do whatever it wants to do, you are not to question the sanity
> >> and you are not to request any kind of rules - give us the fucking syscall
> >> arguments and let us at it".
> > 
> > I'm not going to comment on past remarks made by other devs, but I do
> > want to make it clear that I am interested in making sure we have LSM
> > hooks which satisfy both the needs of the existing in-tree LSMs while
> > also presenting a sane API to the kernel subsystems in which they are
> > placed.  I'm happy to revisit any of our existing LSM hooks to
> > restructure them to better fit these goals; simply send some patches
> > and let's discuss them.
> > 
> >> Come up with a saner API.  We are done accomodating that idiocy.  The only
> >> changes you get to make in fs/namespace.c are "here's our better-defined
> >> hooks, please call <this hook> when you do <that>".
> 
> 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.

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.