LSM: Whiteout chardev creation sidesteps mknod hook

[Günther Noack]

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?

—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/