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

["Mickaël Salaün" <mic@digikod.net>]

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.