LSM: Whiteout chardev creation sidesteps mknod hook

["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.


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?

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