LSM: Whiteout chardev creation sidesteps mknod hook

[Mickaël Salaün]

On Tue, Apr 07, 2026 at 03:05:13PM +0200, Günther Noack wrote:
> 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.

Any way to "write" on the filesystem should properly be controlled.  The
man page says that RENAME_WHITEOUT requires CAP_MKNOD, however, looking
at vfs_mknod(), there is an explicit exception to not check CAP_MKNOD
for whiteout devices. See commit a3c751a50fe6 ("vfs: allow unprivileged
whiteout creation").

> 
> 
> 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?

This is the right semantic.

> 
> Do it in the VFS rename hook.
> 
> * Pro: Fixes it for all LSMs
> * Con: Call would have to be done in multiple filesystems

That would not work.

> 
> 
> 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
>   affected filesystems for that.  (That feels like solving it at the
>   wrong layer of abstraction.)

Why would we need to maintain such list?  If it's only about the errno,
well, that would not be perfect be ok with a proper doc.

I'm mostly worried that there might be other (future) call paths to
create whiteout devices.

I think option 2 would be the most practical approach for Landlock, with
a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right.

I'm also wondering how are the chances that other kind of special file
type like a whiteout device could come up in the future.  Any guess
Christian?

> * Con: Unclear whether other LSMs need a similar fix

I guess at least AppArmor and Tomoyo would consider that an issue.

> 
> 
> Option 3: Declare that this is working as intended?

We need to be able to controle any file creation, which is not currently
the case because of this whiteout exception.

> 
> * 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.
>