[PATCH v2 1/7] lsm: Add granular mount hooks to replace security_sb_mount

[Song Liu]

On Fri, May 8, 2026 at 1:53 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, May 8, 2026 at 4:29 PM Song Liu <song at kernel.org> wrote:
> > On Fri, May 8, 2026 at 1:10 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Wed, Apr 29, 2026 at 8:03 PM Song Liu <song at kernel.org> wrote:
> > > >
> > > > Add six new LSM hooks for mount operations:
> > > >
> > > > - mount_bind(from, to, recurse): bind mount with pre-resolved
> > > >   struct path for source and destination.
> > > > - mount_new(fc, mp, mnt_flags, flags, data): new mount, called after
> > > >   mount options are parsed. The flags and data parameters carry the
> > > >   original mount(2) flags and data for LSMs that need them (AppArmor,
> > > >   Tomoyo).
> > > > - mount_remount(fc, mp, mnt_flags, flags, data): filesystem remount,
> > > >   called after mount options are parsed into the fs_context.
> > > > - mount_reconfigure(mp, mnt_flags, flags): mount flag reconfiguration
> > > >   (MS_REMOUNT|MS_BIND path).
> > > > - mount_move(from, to): move mount with pre-resolved paths.
> > > > - mount_change_type(mp, ms_flags): propagation type changes.
> > > >
> > > > These replace the monolithic security_sb_mount() which conflates
> > > > multiple distinct operations into a single hook, and suffers from
> > > > TOCTOU issues where LSMs re-resolve string-based dev_name via
> > > > kern_path().
> > > >
> > > > The mount_move hook is added alongside the existing move_mount hook.
> > > > During the transition, LSMs register for both hooks. The move_mount
> > > > hook will be removed once all LSMs have been converted.
> > > >
> > > > Some LSMs, such as apparmor and tomoyo, audit the original input passed
> > > > in the mount syscall. To keep the same behavior, argument data and flags
> > > > are passed in do_* functions. These can be removed if these LSMs no
> > > > longer need these information.
> > > >
> > > > All new hooks are registered as sleepable BPF LSM hooks.
> > > >
> > > > Code generated with the assistance of Claude, reviewed by human.
> > > >
> > > > Reviewed-by: Stephen Smalley <stephen.smalley.work at gmail.com>
> > > > Tested-by: Stephen Smalley <stephen.smalley.work at gmail.com> # for selinux only
> > > > Signed-off-by: Song Liu <song at kernel.org>
> > > > ---
> > > >  fs/namespace.c                |  35 ++++++++++--
> > > >  include/linux/lsm_hook_defs.h |  12 ++++
> > > >  include/linux/security.h      |  50 +++++++++++++++++
> > > >  kernel/bpf/bpf_lsm.c          |   7 +++
> > > >  security/security.c           | 101 ++++++++++++++++++++++++++++++++++
> > > >  5 files changed, 199 insertions(+), 6 deletions(-)
> > >
> > > ...
> > >
> > > > @@ -3708,6 +3724,10 @@ static int do_move_mount_old(const struct path *path, const char *old_name)
> > > >         if (err)
> > > >                 return err;
> > > >
> > > > +       err = security_mount_move(&old_path, path);
> > > > +       if (err)
> > > > +               return err;
> > > > +
> > > >         return do_move_mount(&old_path, path, 0);
> > > >  }
> > >
> > > While the security_sb_mount() hook calls into do_move_mount_old(), the
> > > security_move_mount() hook calls into do_mount_mount().  As you remove
> > > both of these LSM hooks in patch 7/7, should we consider moving the
> > > new security_mount_move() into do_move_mount()?  If not, how do we
> > > ensure that we don't lose coverage when removing the
> > > security_move_mount() hook, or can you explain why it is not needed?
>
> Ooof, I just read my comment above - that was all mixed up, my
> apologies.  Evidently it's been a long week ...
>
> > Patch 7/7 _replaces_ security_move_mount() with security_mount_move()
> > in vfs_move_mount().
>
> Okay, at the very least you should probably change the subject line to
> patch 7/7, or ideally move that hook addition/modification to patch
> 1/7 so patch 7/7 is purely an unused-hook-removal patch.
>
> > IOW, security_mount_move() is called from both
> > vfs_move_mount() and do_move_mount_old(), so we are not losing any
> > coverage. Did I miss something?
>
> No, I assumed patch 7/7 was doing something different based solely on
> the subject line.
>
> Let's also put the vfs_move_mount()/security_mount_move() change in
> patch 1/7 so that patch 7/7 is simply a hook/dead-code removal patch.
> This should make the patchset much cleaner.

Sounds good. I will make the change in v3.

Thanks,
Song