linux-kernel - Re: [PATCH v3 2/2] landlock: add support for private bind mount

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250123.eSh0aipetesh@digikod.net>
Date: Thu, 23 Jan 2025 22:08:28 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Shervin Oloumi <enlightened@...omium.org>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz, 
	paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com, 
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, gnoack@...gle.com, 
	shuah@...nel.org, jorgelo@...omium.org, allenwebb@...omium.org
Subject: Re: [PATCH v3 2/2] landlock: add support for private bind mount

On Thu, Jan 23, 2025 at 09:34:50PM +0100, Mickaël Salaün wrote:
> On Thu, Jan 09, 2025 at 06:10:08PM -0800, Shervin Oloumi wrote:

> > Finally, any existing mounts or bind mounts before the process enters a
> > LandLock domain remain as they are. Such mounts can be of the shared
> > propagation type, and they would continue to share updates with the rest
> > of their peer group. While this is an existing behavior, after this
> > patch
> 
> > such mounts can also be remounted as private,
> 
> OK
> 
> > or be unmounted after the process enters the sandbox.
> 
> As Christian pointed out, being able to unmount pre-sandbox mount points
> could give access to previously-hidden files.  For unmounts, we should
> have a dedicated LANDLOCK_ACCESS_FS_UNMOUNT right and highlight in the
> documentation the risk of unveiling hidden files.

Instead of a new access right, a better approach would be to require the
LANDLOCK_ACCESS_FS_MOUNT and that the mount point was created by the
task trying to unmount it (or one with less privileges).  This could be
done by recording the mount task's credential in struct
landlock_superblock_security and then checking that the task requesting
the unmount can ptrace this (mount) credential.

> 
> > Existing mounts are outside the
> > scope of LandLock and should be considered before entering the sandbox.