Message-ID: <20260121-eilverfahren-bohrung-dd89404fbe3b@brauner>
Date: Wed, 21 Jan 2026 11:20:23 +0100
From: Christian Brauner <brauner@...nel.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: Andy Lutomirski <luto@...capital.net>, 
	Askar Safin <safinaskar@...il.com>, amir73il@...il.com, cyphar@...har.com, jack@...e.cz, 
	josef@...icpanda.com, linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk, 
	Lennart Poettering <mzxreary@...inter.de>, David Howells <dhowells@...hat.com>, 
	Zhang Yunkai <zhang.yunkai@....com.cn>, cgel.zte@...il.com, Menglong Dong <menglong8.dong@...il.com>, 
	linux-kernel@...r.kernel.org, initramfs@...r.kernel.org, containers@...ts.linux.dev, 
	linux-api@...r.kernel.org, news@...ronix.com, lwn@....net, Jonathan Corbet <corbet@....net>, 
	Rob Landley <rob@...dley.net>, emily@...coat.dev, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 0/2] mount: add OPEN_TREE_NAMESPACE

On Mon, Jan 19, 2026 at 05:21:30PM -0500, Jeff Layton wrote:
> On Mon, 2026-01-19 at 11:05 -0800, Andy Lutomirski wrote:
> > On Mon, Jan 19, 2026 at 10:56 AM Askar Safin <safinaskar@...il.com> wrote:
> > > 
> > > Christian Brauner <brauner@...nel.org>:
> > > > Extend open_tree() with a new OPEN_TREE_NAMESPACE flag. Similar to
> > > > OPEN_TREE_CLONE only the indicated mount tree is copied. Instead of
> > > > returning a file descriptor referring to that mount tree
> > > > OPEN_TREE_NAMESPACE will cause open_tree() to return a file descriptor
> > > > to a new mount namespace. In that new mount namespace the copied mount
> > > > tree has been mounted on top of a copy of the real rootfs.
> > > 
> > > I want to point at security benefits of this.
> > > 
> > > [[ TL;DR: [1] and [2] are very big changes to how mount namespaces work.
> > > I like them, and I think they should get wider exposure. ]]
> > > 
> > > If this patchset ([1]) and [2] both land (they are both in "next" now and
> > > likely will be submitted to mainline soon) and "nullfs_rootfs" is passed on
> > > command line, then mount namespace created by open_tree(OPEN_TREE_NAMESPACE) will
> > > usually contain exactly 2 mounts: nullfs and whatever was passed to
> > > open_tree(OPEN_TREE_NAMESPACE).
> > > 
> > > This means that even if attacker somehow is able to unmount its root and
> > > get access to underlying mounts, then the only underlying thing they will
> > > get is nullfs.
> > > 
> > > Also this means that other mounts are not only hidden in new namespace, they
> > > are fully absent. This prevents attacks discussed here: [3], [4].
> > > 
> > > Also this means that (assuming we have both [1] and [2] and "nullfs_rootfs"
> > > is passed), there is no anymore hidden writable mount shared by all containers,
> > > potentially available to attackers. This is concern raised in [5]:
> > > 
> > > > You want rootfs to be a NULLFS instead of ramfs. You don't seem to want it to
> > > > actually _be_ a filesystem. Even with your "fix", containers could communicate
> > > > with each _other_ through it if it becomes accessible. If a container can get
> > > > access to an empty initramfs and write into it, it can ask/answer the question
> > > > "Are there any other containers on this machine running stux24" and then coordinate.
> > 
> > I think this new OPEN_TREE_NAMESPACE is nifty, but I don't think the
> > path that gives it sensible behavior should be conditional like this.
> > Either make it *always* mount on top of nullfs (regardless of boot
> > options) or find some way to have it actually be the root.  I assume
> > the latter is challenging for some reason.
> > 
> 
> I think that's the plan. I suggested the same to Christian last week,
> and he was amenable to removing the option and just always doing a
> nullfs_rootfs mount.

Whether or not the underlying mount is nullfs or not is irrelevant. If
it's not nullfs but a regular tmpfs it works just as well. If it has any
locked overmounts the new rootfs will become locked as well similarly if
it'll be owned by a new userns.

Powered by blists - more mailing lists