linux-kernel - Re: [RFC] vfs: security: Parse dev_name before calling security_sb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhSS1O+Cp7UJoJnWNbv-Towia72DitOPH0zmKCa4PBttkw@mail.gmail.com>
Date: Wed, 9 Jul 2025 11:19:30 -0400
From: Paul Moore <paul@...l-moore.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Song Liu <song@...nel.org>, bpf@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, 
	apparmor@...ts.ubuntu.com, selinux@...r.kernel.org, 
	tomoyo-users_en@...ts.sourceforge.net, tomoyo-users_ja@...ts.sourceforge.net, 
	kernel-team@...a.com, andrii@...nel.org, eddyz87@...il.com, ast@...nel.org, 
	daniel@...earbox.net, martin.lau@...ux.dev, brauner@...nel.org, jack@...e.cz, 
	kpsingh@...nel.org, mattbobrowski@...gle.com, amir73il@...il.com, 
	repnop@...gle.com, jlayton@...nel.org, josef@...icpanda.com, mic@...ikod.net, 
	gnoack@...gle.com, m@...wtm.org, john.johansen@...onical.com, 
	john@...armor.net, stephen.smalley.work@...il.com, omosnace@...hat.com, 
	takedakn@...data.co.jp, penguin-kernel@...ove.sakura.ne.jp, 
	enlightened@...omium.org
Subject: Re: [RFC] vfs: security: Parse dev_name before calling security_sb_mount

On Wed, Jul 9, 2025 at 6:24 AM Al Viro <viro@...iv.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>".

I don't have the cycles to revisit the security_sb_mount() hook
myself, but perhaps Song Liu does with some suggestions/guidance from
you or Christian on what an improved LSM hook would look like from a
VFS perspective.

-- 
paul-moore.com