LSM: Whiteout chardev creation sidesteps mknod hook

[Stephen Smalley]

On Mon, Apr 13, 2026 at 8:24 AM Günther Noack <gnoack at google.com> wrote:
>
> On Mon, Apr 13, 2026 at 12:18:08PM +0200, Miklos Szeredi wrote:
> > On Sat, 11 Apr 2026 at 10:36, Günther Noack <gnoack at google.com> wrote:
> > > I also don't currently see how an attacker would abuse this, but I still see
> > > this as a violation of Landlock's security model if we can create a policy that
> > > denies the creation of character device directory entries, and then we still
> > > have a way to make them appear there where we previously had a different file.
> >
> > Look: a whiteout is a whiteout, NOT a character device.  Don't let the
> > fact that it's represented by "c 0 0" fool you, this is a completely
> > different beast.  See commit a3c751a50fe6 ("vfs: allow unprivileged
> > whiteout creation").
> >
> > Does this beast need special handling by LSMs?  I have no idea, but
> > treating them the same as char devs sounds like a bad idea.
>
> Thanks for the pointer to that commit.  I was under the impression
> that creation of the whiteout objects required CAP_MKNOD, but it seems
> you have dropped that requirement in that commit.
>
> (FWIW, I was mislead by the rename(2) man page[1], which is apparently
> not up to date and where it explicitly says:
>
>     RENAME_WHITEOUT requires the same privileges as creating a
>     device node (i.e., the CAP_MKNOD capability).
>
> So with that assumption, it seemed natural that this should have
> extended equivalently into a Landlock policy.)
>
> So if the "c 0 0" whiteout device is indeed a different kind of file,
> maybe we would need to treat it with a separate Landlock access right
> after all then.  I'll ponder it.
>
> FWIW, besides introducing a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
> access right and adding more special cases to the Landlock API,
> another possible option might be to just forbid creating whiteout
> objects altogether, when under a Landlock policy.  As the man page
> also notes, "This operation makes sense only for overlay/union
> filesystem implementations", and since these likely can't use Landlock
> anyway due to mounting, I think there would be no use case left where
> anyone would want to perform such an operation within a Landlock
> domain -- I don't think this would break anyone.  Mickaël, do you have
> an opinion on that idea?

Just as a point of comparison, for SELinux, I see the following
permission checks occur upon renameat2(..., RENAME_WHITEOUT):
1. add_name, write, and search permissions to the destination dir
2. rename permission to the source file
3. if the dst file already exists, unlink permission to the dst file
4. remove_name, write, and search permissions to the source dir

And the following permission checks upon mknod(..., S_IFCHR, 0):
1. add_name, write, and search permissions to the destination dir
2. create permission to the new chr_file

So we are missing the create check for the whiteout file on
renameat2(); not sure if that's working as intended or a bug.

>
> —Günther
>
> P.S. Initial patch set from Saturday is at [2], but this still uses
> the LANDLOCK_ACCESS_FS_MAKE_CHAR right.
>
> [1] https://man7.org/linux/man-pages/man2/rename.2.html
> [2] https://lore.kernel.org/all/20260411090944.3131168-2-gnoack@google.com/