Re: Landlock: mount_setattr(2) is unmediated by LSMs (ro-mount confinement bypass)

On Sat, Jul 18, 2026 at 03:44:50PM +0530, Vivek Parikh wrote:
> Hi Mickaël, Christian,
> 
> Note: this was found with AI assistance, so I am treating it as public per
> Documentation/process/security-bugs.
> 
> While auditing Landlock's filesystem-topology restrictions I found that
> mount_setattr(2) is not mediated by any LSM. It only matters for a
> sandboxed task that holds CAP_SYS_ADMIN in its own user namespace -- the
> rootful-container / userns-root profile that landlock_restrict_self()
> explicitly supports (security/landlock/syscalls.c). Fully unprivileged
> callers are not affected.
> 
> do_mount_setattr() (fs/namespace.c:4928) -> mount_setattr_prepare() has no
> security_* hook anywhere on its path, whereas mount(2), move_mount(2),
> umount(2), remount and pivot_root(2) all do (security_sb_mount,
> security_move_mount, security_sb_umount, security_sb_remount,
> security_sb_pivotroot). Landlock hooks exactly those five in
> security/landlock/fs.c (hook_sb_mount, hook_move_mount, hook_sb_umount,
> hook_sb_remount, hook_sb_pivotroot) but cannot see mount_setattr(2).
> 
> Documentation/userspace-api/landlock.rst ("Filesystem topology
> modification") states that sandboxed threads cannot modify filesystem
> topology, but such a task can still, via mount_setattr(2):
> 
>   1. Clear MOUNT_ATTR_RDONLY on a read-only (bind) mount and write through
>      it -- subverting the common ro-bind-mount confinement pattern.
>   2. Change mount propagation (shared/private/slave/unbindable).
>   3. Request MOUNT_ATTR_IDMAP changes (narrower in practice: gated by
>      can_idmap_mount()).
> 
> This is a mediation/coverage gap, not a rule-evaluation bug: Landlock's
> filesystem access-rights checks still apply on top. The issue is that the
> ro-mount / propagation / idmap layer of a confinement -- which sandbox
> setups rely on -- is changeable despite the documented topology
> restriction. It affects every LSM, not just Landlock (SELinux, AppArmor
> and Smack cannot mediate mount_setattr(2) either).
> 
> A self-contained unprivileged reproducer (userns+mountns, no external
> privilege) is available on request; I am not inlining it here. Its output,
> on 7.0.0-27-generic (host) and reproduced on 7.2.0-rc3 (QEMU guest,
> CONFIG_SECURITY_LANDLOCK=y):
> 
>   [1] write via ro mount before Landlock: Read-only file system (expected)
>   [2] Landlock enforced (all fs accesses allowed via rule on /)
>   [3] mount(2) under Landlock: Operation not permitted (expected EPERM)
>   [4] mount_setattr(rw-flip) under Landlock: SUCCESS  <-- gap
>   [5] write via formerly-ro mount: SUCCEEDED  <-- confinement subverted
> 
> mount(2) is correctly denied (step 3) while the equivalent attribute
> change via mount_setattr(2) succeeds (step 4) and makes the previously
> read-only tree writable (step 5).
> 
> I could not find an existing LSM hook for this in v7.2-rc3. If this is a
> known and accepted limitation (the v30 Landlock series was synchronized
> with mount_setattr(2)), then documenting it in landlock.rst -- the
> "Filesystem topology modification" section currently names only mount(2)
> and pivot_root(2) -- would already help. Otherwise, the consistent fix
> would be to add a security_sb_mount_setattr() LSM hook in
> do_mount_setattr() and wire Landlock's topology denial to it, mirroring
> hook_sb_remount(). I am happy to prepare that patch (plus a
> tools/testing/selftests/landlock/ test) if you agree with the direction.

Song is working on this.