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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Replacing the legacy `sb_mount` and `move_mount` LSM hooks with new granular mount hooks without updating the VFS callers completely drops Landlock's (as well as AppArmor's and SELinux's) mount sandbox protections.
--

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

landlock: Convert from sb_mount to granular mount hooks

This commit replaces Landlock's legacy sb_mount and move_mount hooks
with granular mount hooks (mount_bind, mount_new, etc.). The new hooks
are wired to a common helper that denies all mount operations for
sandboxed processes.

> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index c1ecfe2390326..4e6712f972f0a 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c

[ ... ]

> @@ -1950,8 +1978,12 @@ static struct security_hook_list landlock_hooks[] __ro_after_init = {
>  	LSM_HOOK_INIT(inode_free_security_rcu, hook_inode_free_security_rcu),
>  
>  	LSM_HOOK_INIT(sb_delete, hook_sb_delete),
> -	LSM_HOOK_INIT(sb_mount, hook_sb_mount),
> -	LSM_HOOK_INIT(move_mount, hook_move_mount),
> +	LSM_HOOK_INIT(mount_bind, hook_mount_bind),
> +	LSM_HOOK_INIT(mount_new, hook_mount_new),
> +	LSM_HOOK_INIT(mount_remount, hook_mount_remount),
> +	LSM_HOOK_INIT(mount_reconfigure, hook_mount_reconfigure),
> +	LSM_HOOK_INIT(mount_change_type, hook_mount_change_type),
> +	LSM_HOOK_INIT(mount_move, hook_move_mount),

[Severity: Critical]
Does this conversion inadvertently bypass Landlock's mount protections?

Looking at path_mount() in fs/namespace.c, the VFS still relies on the legacy
security_sb_mount() API:

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

And this wrapper strictly evaluates the legacy sb_mount hook list:

security/security.c:security_sb_mount() {
    return call_int_hook(sb_mount, dev_name, path, type, flags, data);
}

Similarly, vfs_move_mount() in fs/namespace.c still calls the legacy
security_move_mount() API.

Because this patch removes sb_mount and move_mount from landlock_hooks, won't
these VFS calls find an empty hook list for Landlock and unconditionally return
0 (success), allowing unprivileged sandboxed processes to perform unauthorized
mounts?

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

  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 [this message]
2026-07-06 23:50 ` [PATCH v6 6/8] tomoyo: " Song Liu
2026-07-07  0:04   ` sashiko-bot
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=20260707000438.5A3261F000E9@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.