Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Christian Brauner <brauner@kernel.org>]

On Tue, Apr 07, 2026 at 12:15:00PM -0500, Serge Hallyn wrote:
> Apr 7, 2026 08:05:43 Günther Noack <gnoack@google.com>:
> 
> > Hello Christian, Paul, Mickaël and LSM maintainers!
> >
> > I discovered the following bug in Landlock, which potentially also
> > affects other LSMs:
> >
> > With renameat2(2)'s RENAME_WHITEOUT flag, it is possible to create a
> > "whiteout object" at the source of the rename.  Whiteout objects are
> > character devices with major/minor (0, 0) -- these devices are not
> > bound to any driver, so they are harmless, but still, the creation of
> > these files can sidestep the LANDLOCK_ACCESS_FS_MAKE_CHAR access right
> > in Landlock.

They aren't devices.

> >
> >
> > I am unconvinced which is the right fix here -- do you have an opinion
> > on this from the VFS/LSM side?
> >
> >
> > Option 1: Make filesystems call security_path_mknod() during RENAME_WHITEOUT?

No.

> >
> > Do it in the VFS rename hook.
> >
> > * Pro: Fixes it for all LSMs
> > * Con: Call would have to be done in multiple filesystems
> >
> >
> > Option 2: Handle it in security_{path,inode}_rename()
> >
> > Make Landlock handle it in security_inode_rename() by looking for the
> > RENAME_WHITEOUT flag.
> >
> > * Con: Operation should only be denied if the file system even
> >   implements RENAME_WHITEOUT, and we would have to maintain a list of

Why? Just deny RENAME_WHITEOUT. What does it matter if the filesystem
implements it or not. Overlayfs would fall back to non-RENAME_WHITEOUT
if not provided by the upper fs anway.

> >   affected filesystems for that.  (That feels like solving it at the
> >   wrong layer of abstraction.)
> > * Con: Unclear whether other LSMs need a similar fix
> >
> >
> > Option 3: Declare that this is working as intended?
> 
> Option 3 has my vote.

Seconded.

> 
> 
> > * Pro: (0, 0) is not a "real" character device
> >
> >
> > In cases 1 and 2, we'd likely need to double check that we are not
> > breaking existing scenarios involving OverlayFS, by suddenly requiring
> > a more lax policy for creating character devices on these directories.
> >
> > Please let me know what you think.  I'm specifically interested in:
> >
> > 1. Christian: What is the appropriate way to do this VFS wise?
> > 2. LSM maintainers: Is this a bug that affects other LSMs as well?
> >
> > Thanks,
> > —Günther
> >
> > P.S.: For full transparency, I found this bug by pointing Google
> > Gemini at the Landlock codebase.

Clearly.