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 for Android: free password hash cracker in your pocket

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

Message-ID: <1959367A-15AB-4332-B1BC-7BBCCA646636@meta.com>
Date: Wed, 9 Jul 2025 17:06:36 +0000
From: Song Liu <songliubraving@...a.com>
To: Paul Moore <paul@...l-moore.com>
CC: Al Viro <viro@...iv.linux.org.uk>, Song Liu <song@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-security-module@...r.kernel.org"
	<linux-security-module@...r.kernel.org>,
        "apparmor@...ts.ubuntu.com"
	<apparmor@...ts.ubuntu.com>,
        "selinux@...r.kernel.org"
	<selinux@...r.kernel.org>,
        "tomoyo-users_en@...ts.sourceforge.net"
	<tomoyo-users_en@...ts.sourceforge.net>,
        "tomoyo-users_ja@...ts.sourceforge.net"
	<tomoyo-users_ja@...ts.sourceforge.net>,
        Kernel Team <kernel-team@...a.com>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "eddyz87@...il.com"
	<eddyz87@...il.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "martin.lau@...ux.dev"
	<martin.lau@...ux.dev>,
        "brauner@...nel.org" <brauner@...nel.org>,
        "jack@...e.cz" <jack@...e.cz>,
        "kpsingh@...nel.org" <kpsingh@...nel.org>,
        "mattbobrowski@...gle.com" <mattbobrowski@...gle.com>,
        "amir73il@...il.com"
	<amir73il@...il.com>,
        "repnop@...gle.com" <repnop@...gle.com>,
        "jlayton@...nel.org" <jlayton@...nel.org>,
        "josef@...icpanda.com"
	<josef@...icpanda.com>,
        "mic@...ikod.net" <mic@...ikod.net>,
        "gnoack@...gle.com" <gnoack@...gle.com>, "m@...wtm.org" <m@...wtm.org>,
        "john.johansen@...onical.com" <john.johansen@...onical.com>,
        "john@...armor.net" <john@...armor.net>,
        "stephen.smalley.work@...il.com"
	<stephen.smalley.work@...il.com>,
        "omosnace@...hat.com"
	<omosnace@...hat.com>,
        "takedakn@...data.co.jp" <takedakn@...data.co.jp>,
        "penguin-kernel@...ove.sakura.ne.jp" <penguin-kernel@...ove.sakura.ne.jp>,
        "enlightened@...omium.org" <enlightened@...omium.org>
Subject: Re: [RFC] vfs: security: Parse dev_name before calling
 security_sb_mount

Hi Al and Paul, 

Thanks for your comments!

> On Jul 9, 2025, at 8:19 AM, Paul Moore <paul@...l-moore.com> wrote:
> 
> 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>".

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 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.

Thanks,
Song