Re: LSM: Whiteout chardev creation sidesteps mknod hook

["Mickaël Salaün" <mic@digikod.net>]

On Mon, Apr 13, 2026 at 02:23:05PM +0200, Günther Noack 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@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.)

I agree with Miklos and also pointed out to this commit:
https://lore.kernel.org/all/20260408.beu1Eing5aFo@digikod.net/

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

What is sure is that we should not treat it like character devices,
which required special capabilities/permissions because they are a door
to a driver interface.

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

This doesn't feel right.  Mount operations restriction are there because
Landlock currently cannot properly control mount operations yet (see
https://github.com/landlock-lsm/linux/issues/14).

> As the man page
> also notes, "This operation makes sense only for overlay/union
> filesystem implementations",

The man pages contain at least one important error wrt this feature, so
we should only trust the kernel code.  Anyway, anyone can create a
whiteout with mknod, so let's consider that there are other use cases.

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

The LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right makes sense wrt other MAKE_*
rights (i.e. per file type).  See may detailed reply here:
https://lore.kernel.org/r/20260414.Lae5ida1eeGh@digikod.net

BTW, I don't understand why only the renameat2(2) syscall can
(indirectly) create this file type; why not also unlink(2) or rmdir(2)?

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