LSM: Whiteout chardev creation sidesteps mknod hook

Serge Hallyn serge at hallyn.com
Tue Apr 7 17:15:00 UTC 2026


Apr 7, 2026 08:05:43 Günther Noack <gnoack at 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.
>
>
> 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?
>
> 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
>   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.


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




More information about the Linux-security-module-archive mailing list