All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
Cc: selinux@vger.kernel.org
Subject: Re: [PATCH v6 6/8] tomoyo: Convert from sb_mount to granular mount hooks
Date: Tue, 07 Jul 2026 00:04:04 +0000	[thread overview]
Message-ID: <20260707000404.E86741F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706235053.4104951-7-song@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch series introduces a complete access control bypass for mount operations across all LSMs (Tomoyo, AppArmor, SELinux, Landlock).
--

--- Patch [6]: [PATCH v6 6/8] tomoyo: Convert from sb_mount to granular mount hooks ---
commit b14cd8de9e00724d26864e133cbd2962345e3c1c
Author: Song Liu <song@kernel.org>

tomoyo: Convert from sb_mount to granular mount hooks

This patch replaces tomoyo_sb_mount() with granular mount hooks. Each hook
reconstructs the MS_* flags expected by tomoyo_mount_permission() to perform
security checks for bind mounts, new mounts, remounts, and other operations.

> diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> index c66e02ed8ee3b..eec3df35e28e5 100644
> --- a/security/tomoyo/tomoyo.c
> +++ b/security/tomoyo/tomoyo.c
[ ... ]
> @@ -576,7 +662,12 @@ static struct security_hook_list tomoyo_hooks[] __ro_after_init = {
>  	LSM_HOOK_INIT(path_chmod, tomoyo_path_chmod),
>  	LSM_HOOK_INIT(path_chown, tomoyo_path_chown),
>  	LSM_HOOK_INIT(path_chroot, tomoyo_path_chroot),
> -	LSM_HOOK_INIT(sb_mount, tomoyo_sb_mount),
> +	LSM_HOOK_INIT(mount_bind, tomoyo_mount_bind),
> +	LSM_HOOK_INIT(mount_new, tomoyo_mount_new),
> +	LSM_HOOK_INIT(mount_remount, tomoyo_mount_remount),
> +	LSM_HOOK_INIT(mount_reconfigure, tomoyo_mount_reconfigure),
> +	LSM_HOOK_INIT(mount_change_type, tomoyo_mount_change_type),
> +	LSM_HOOK_INIT(mount_move, tomoyo_mount_move),
>  	LSM_HOOK_INIT(sb_umount, tomoyo_sb_umount),

[Severity: Critical]
By removing the sb_mount hook here, does this introduce a regression where
mount access control policies are entirely bypassed during a git bisect?

Looking at path_mount() in fs/namespace.c, the VFS layer still relies on the
legacy security_sb_mount() wrapper which calls the sb_mount hook:

fs/namespace.c:path_mount() {
    ...
    ret = security_sb_mount(dev_name, path, type_page, flags, data_page);
    if (ret)
        return ret;
    ...
}

If this patch is applied before the VFS layer is updated to invoke the new
security_mount_* hooks, wouldn't security_sb_mount() simply evaluate to 0
since the LSM no longer implements sb_mount? This seems to unconditionally
allow mounts that should be denied by policy.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706235053.4104951-1-song@kernel.org?part=6

  reply	other threads:[~2026-07-07  0:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 23:50 [PATCH v6 0/8] lsm: Replace security_sb_mount with granular mount hooks Song Liu
2026-07-06 23:50 ` [PATCH v6 1/8] lsm: Add " Song Liu
2026-07-07  0:00   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 2/8] apparmor: Remove redundant MS_MGC_MSK stripping in apparmor_sb_mount Song Liu
2026-07-07  0:04   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 3/8] apparmor: Convert from sb_mount to granular mount hooks Song Liu
2026-07-07  0:05   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 4/8] selinux: " Song Liu
2026-07-07  0:01   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 5/8] landlock: " Song Liu
2026-07-07  0:04   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 6/8] tomoyo: " Song Liu
2026-07-07  0:04   ` sashiko-bot [this message]
2026-07-06 23:50 ` [PATCH v6 7/8] vfs: Replace security_sb_mount/security_move_mount with granular hooks Song Liu
2026-07-07  0:06   ` sashiko-bot
2026-07-06 23:50 ` [PATCH v6 8/8] lsm: Remove security_sb_mount and security_move_mount Song Liu
2026-07-07  2:08   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260707000404.E86741F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.