LSM: Whiteout chardev creation sidesteps mknod hook

LSM: Whiteout chardev creation sidesteps mknod hook

[Günther Noack]

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.

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Serge Hallyn]

Apr 7, 2026 08:05:43 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?

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.

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Christian Brauner]

On Tue, Apr 07, 2026 at 12:15:00PM -0500, Serge Hallyn wrote:
> Apr 7, 2026 08:05:43 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.

They aren't devices.

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

No.

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

Why? Just deny RENAME_WHITEOUT. What does it matter if the filesystem
implements it or not. Overlayfs would fall back to non-RENAME_WHITEOUT
if not provided by the upper fs anway.

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

Seconded.

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

Clearly.

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Günther Noack]

On Thu, Apr 09, 2026 at 02:47:16PM +0200, Christian Brauner wrote:
> On Tue, Apr 07, 2026 at 12:15:00PM -0500, Serge Hallyn wrote:
> > Apr 7, 2026 08:05:43 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.
> 
> They aren't devices.

The LANDLOCK_ACCESS_FS_MAKE_CHAR access right is about the *creation of
character device directory entries*.

These files do not hook up to any of the kernel's device driver subsystems, but
they *are* directory entries of the chardev type, and the creation of these is
still sidestepping the LANDLOCK_ACCESS_FS_MAKE_CHAR right.


> > > 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?
> 
> No.
> 
> > >
> > > 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
> 
> Why? Just deny RENAME_WHITEOUT. What does it matter if the filesystem
> implements it or not. Overlayfs would fall back to non-RENAME_WHITEOUT
> if not provided by the upper fs anway.

I'll send a patch with this approach for discussion.

It turns out it is less difficult than I feared:

* OverlayFS uses its own credentials object, and since that is not under a
  Landlock policy, the OverlayFS-internal vfs_rename() invocations do not have
  that problem.  (Under a Landlock policy, mount(2) is not permitted, so the
  OverlayFS-internal credentials are not Landlocked.)
* The remaining use case is only when a user calls renameat2(...,
  RENAME_WHITEOUT) directly on a filesystem (which is not necessarily part of an
  OverlayFS).  That case can be restricted with Landlock.

We might have slight error code inconsistencies yes, but as Mickaël is saying on
the sibling mail thread, it would not be worth the tradeoff to maintain a list
of supported file systems just to get the error codes right.


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

(See also discussion on sibling thread)

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.

I'll send a tentative patch for option 2 for discussion. We can discuss more in
the context of that more concrete proposal, if needed.

—Günther

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Mickaël Salaün]

On Tue, Apr 07, 2026 at 03:05:13PM +0200, Günther Noack wrote:
> 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.

Any way to "write" on the filesystem should properly be controlled.  The
man page says that RENAME_WHITEOUT requires CAP_MKNOD, however, looking
at vfs_mknod(), there is an explicit exception to not check CAP_MKNOD
for whiteout devices. See commit a3c751a50fe6 ("vfs: allow unprivileged
whiteout creation").

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

This is the right semantic.

> 
> Do it in the VFS rename hook.
> 
> * Pro: Fixes it for all LSMs
> * Con: Call would have to be done in multiple filesystems

That would not work.

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

Why would we need to maintain such list?  If it's only about the errno,
well, that would not be perfect be ok with a proper doc.

I'm mostly worried that there might be other (future) call paths to
create whiteout devices.

I think option 2 would be the most practical approach for Landlock, with
a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right.

I'm also wondering how are the chances that other kind of special file
type like a whiteout device could come up in the future.  Any guess
Christian?

> * Con: Unclear whether other LSMs need a similar fix

I guess at least AppArmor and Tomoyo would consider that an issue.

> 
> 
> Option 3: Declare that this is working as intended?

We need to be able to controle any file creation, which is not currently
the case because of this whiteout exception.

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

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Mickaël Salaün]

CCing fsdevel and Alejandro.

On Wed, Apr 08, 2026 at 01:01:31PM +0200, Mickaël Salaün wrote:
> On Tue, Apr 07, 2026 at 03:05:13PM +0200, Günther Noack wrote:
> > 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.
> 
> Any way to "write" on the filesystem should properly be controlled.  The
> man page says that RENAME_WHITEOUT requires CAP_MKNOD, however, looking
> at vfs_mknod(), there is an explicit exception to not check CAP_MKNOD
> for whiteout devices. See commit a3c751a50fe6 ("vfs: allow unprivileged
> whiteout creation").
> 
> > 
> > 
> > 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?
> 
> This is the right semantic.
> 
> > 
> > Do it in the VFS rename hook.
> > 
> > * Pro: Fixes it for all LSMs
> > * Con: Call would have to be done in multiple filesystems
> 
> That would not work.
> 
> > 
> > 
> > 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.)
> 
> Why would we need to maintain such list?  If it's only about the errno,
> well, that would not be perfect be ok with a proper doc.
> 
> I'm mostly worried that there might be other (future) call paths to
> create whiteout devices.
> 
> I think option 2 would be the most practical approach for Landlock, with
> a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right.
> 
> I'm also wondering how are the chances that other kind of special file
> type like a whiteout device could come up in the future.  Any guess
> Christian?
> 
> > * Con: Unclear whether other LSMs need a similar fix
> 
> I guess at least AppArmor and Tomoyo would consider that an issue.
> 
> > 
> > 
> > Option 3: Declare that this is working as intended?
> 
> We need to be able to controle any file creation, which is not currently
> the case because of this whiteout exception.
> 
> > 
> > * 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.
> > 

Re: LSM: Whiteout chardev creation sidesteps mknod hook

[Günther Noack]

On Wed, Apr 08, 2026 at 01:01:28PM +0200, Mickaël Salaün wrote:
> On Tue, Apr 07, 2026 at 03:05:13PM +0200, Günther Noack wrote:
> > 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.
> 
> Any way to "write" on the filesystem should properly be controlled.  The
> man page says that RENAME_WHITEOUT requires CAP_MKNOD, however, looking
> at vfs_mknod(), there is an explicit exception to not check CAP_MKNOD
> for whiteout devices. See commit a3c751a50fe6 ("vfs: allow unprivileged
> whiteout creation").

Agreed, it should be possible to restrict it.


> > 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.)
> 
> Why would we need to maintain such list?  If it's only about the errno,
> well, that would not be perfect be ok with a proper doc.

Yes, it would be only about the errno.  At the time of writing the initial mail,
I was also worried that OverlayFS would get confused if its internal
vfs_rename() call would sometimes work and sometimes be denied, but as it turns
out, since OverlayFS uses its own credentials internally, this is a non-issue.

I'll send a tentative patch for option 2 for discussion.


> I'm mostly worried that there might be other (future) call paths to
> create whiteout devices.
> 
> I think option 2 would be the most practical approach for Landlock, with
> a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right.

Given that this only affect immediate renameat2() calls, I would actually argue
that we can probably get away with guarding this with the existing
LANDLOCK_ACCESS_FS_MAKE_CHAR right?

I checked Debian code search for usages:
https://codesearch.debian.net/search?q=rename.*RENAME_WHITEOUT&literal=0

Apart from the usual proliferation of copied-around kernel headers and wrapper
pass-through wrapper libraries around renameat2(), the only actual use I found
for the immediate renameat2() syscall with RENAME_WHITEOUT was in fuse-overlayfs
(for the exact same reason).  Fuse-overlayfs is likely not running under a
Landlock policy given that it doesn't have Landlock support itself and given
that it also has to do a mount(), which is forbidden under Landlock, so users
are also unlikely to wrap it in a Landlock domain.


> I'm also wondering how are the chances that other kind of special file
> type like a whiteout device could come up in the future.  Any guess
> Christian?
> 
> > * Con: Unclear whether other LSMs need a similar fix
> 
> I guess at least AppArmor and Tomoyo would consider that an issue.
> 
> > 
> > 
> > Option 3: Declare that this is working as intended?
> 
> We need to be able to controle any file creation, which is not currently
> the case because of this whiteout exception.

Seconded.  Landlock offers a long list of access rights to restrict the creation
of new directory entries, and this is a way to create a new directory entry
anyway.  Even though it's not immediately clear to me how this can be abused for
an actual attack, it is a violation of the previously defined Landlock policy if
directory entries can be created this way.

—Günther