All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Christian Brauner" <brauner@kernel.org>,
	"Serge Hallyn" <serge@hallyn.com>,
	"Amir Goldstein" <amir73il@gmail.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Paul Moore" <paul@paul-moore.com>,
	linux-security-module@vger.kernel.org
Subject: Re: LSM: Whiteout chardev creation sidesteps mknod hook
Date: Mon, 13 Apr 2026 14:23:05 +0200	[thread overview]
Message-ID: <adzgKVIhRj5t3GqM@google.com> (raw)
In-Reply-To: <CAJfpegv6GDFZjdGrQ=0Jahvz5mSgfJr+GvjVwws=SFX-yirpSg@mail.gmail.com>

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

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/

  reply	other threads:[~2026-04-13 12:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 13:05 LSM: Whiteout chardev creation sidesteps mknod hook Günther Noack
2026-04-07 17:15 ` Serge Hallyn
2026-04-09 12:47   ` Christian Brauner
2026-04-11  8:36     ` Günther Noack
2026-04-13 10:18       ` Miklos Szeredi
2026-04-13 12:23         ` Günther Noack [this message]
2026-04-13 17:08           ` Stephen Smalley
2026-04-14 13:42           ` Mickaël Salaün
2026-04-14 14:07             ` Miklos Szeredi
2026-04-08 11:01 ` Mickaël Salaün
2026-04-08 12:24   ` Mickaël Salaün
2026-04-11  8:26   ` Günther Noack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adzgKVIhRj5t3GqM@google.com \
    --to=gnoack@google.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=miklos@szeredi.hu \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.