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] [day] [month] [year] [list]

Message-ID: <20250123.teij3Yungaha@digikod.net>
Date: Thu, 23 Jan 2025 23:02:21 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Shervin Oloumi <enlightened@...omium.org>, brauner@...nel.org
Cc: viro@...iv.linux.org.uk, 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 10:08:30PM +0100, Mickaël Salaün wrote:
> 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.

The superblock cannot be used here, we'll need a new security blob,
probably in struct vfsmount.

Christian, would that be OK with you?

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