From: "Günther Noack" <gnoack@google.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: "Amir Goldstein" <amir73il@gmail.com>,
linux-security-module@vger.kernel.org,
"Jeff Xu" <jeffxu@google.com>, "Arnd Bergmann" <arnd@arndb.de>,
"Jorge Lucangeli Obes" <jorgelo@chromium.org>,
"Allen Webb" <allenwebb@google.com>,
"Dmitry Torokhov" <dtor@google.com>,
"Paul Moore" <paul@paul-moore.com>,
"Konstantin Meskhidze" <konstantin.meskhidze@huawei.com>,
"Matt Bobrowski" <repnop@google.com>,
linux-fsdevel@vger.kernel.org,
"Christian Brauner" <brauner@kernel.org>,
"Mickaël Salaün" <mic@digikod.net>
Subject: Re: [PATCH v13 01/10] landlock: Add IOCTL access right for character and block devices
Date: Fri, 5 Apr 2024 23:44:18 +0200 [thread overview]
Message-ID: <ZhBwstt0zakE4uN2@google.com> (raw)
In-Reply-To: <cnwpkeovzbumhprco7q2c2y6zxzmxfpwpwe3tyy6c3gg2szgqd@vfzjaw5v5imr>
On Fri, Apr 05, 2024 at 02:17:29PM -0400, Kent Overstreet wrote:
> On Fri, Apr 05, 2024 at 06:22:52PM +0200, Günther Noack wrote:
> > Kent, Amir:
> >
> > Is it intentional that the new FS_IOC_GETUUID and FS_IOC_GETFSSYSFSPATH IOCTLs
> > can fall back to a IOCTL implementation in struct file_operations? I found this
> > remark by Amir which sounded vaguely like it might have been on purpose? Did I
> > understand that correctly?
> >
> > https://lore.kernel.org/lkml/CAOQ4uxjvEL4P4vV5SKpHVS5DtOwKpxAn4n4+Kfqawcu+H-MC5g@mail.gmail.com/
> >
> > Otherwise, I am happy to send a patch to make it non-extensible (the impls in
> > fs/ioctl.c would need to return -ENOTTY). This would let us reason better about
> > the safety of these IOCTLs for IOCTL security policies enforced by the Landlock
> > LSM. (Some of these file_operations IOCTL implementations do stuff before
> > looking at the cmd number.)
>
> They're not supposed to be extensible - the generic implementations are
> all we need.
Thank you for confirming, Kent -- I sent you a small patch as part of the next
version of the Landlock patch series:
https://lore.kernel.org/all/20240405214040.101396-2-gnoack@google.com/
—Günther
next prev parent reply other threads:[~2024-04-05 21:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 13:10 [PATCH v13 00/10] Landlock: IOCTL support Günther Noack
2024-03-27 13:10 ` [PATCH v13 01/10] landlock: Add IOCTL access right for character and block devices Günther Noack
2024-03-27 16:57 ` Mickaël Salaün
2024-03-28 12:01 ` Mickaël Salaün
2024-04-02 18:28 ` Günther Noack
2024-04-03 11:15 ` Mickaël Salaün
2024-04-05 16:17 ` Günther Noack
2024-04-05 16:22 ` Günther Noack
2024-04-05 18:04 ` Mickaël Salaün
2024-04-05 18:17 ` Kent Overstreet
2024-04-05 21:44 ` Günther Noack [this message]
2024-04-05 18:01 ` Mickaël Salaün
2024-03-27 13:10 ` [PATCH v13 02/10] selftests/landlock: Test IOCTL support Günther Noack
2024-03-27 16:58 ` Mickaël Salaün
2024-03-27 13:10 ` [PATCH v13 03/10] selftests/landlock: Test IOCTL with memfds Günther Noack
2024-03-27 13:10 ` [PATCH v13 04/10] selftests/landlock: Test ioctl(2) and ftruncate(2) with open(O_PATH) Günther Noack
2024-03-27 13:10 ` [PATCH v13 05/10] selftests/landlock: Test IOCTLs on named pipes Günther Noack
2024-03-27 13:10 ` [PATCH v13 06/10] selftests/landlock: Check IOCTL restrictions for named UNIX domain sockets Günther Noack
2024-03-27 13:10 ` [PATCH v13 07/10] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL_DEV Günther Noack
2024-03-27 13:10 ` [PATCH v13 08/10] landlock: Document IOCTL support Günther Noack
2024-03-27 13:10 ` [PATCH v13 09/10] MAINTAINERS: Notify Landlock maintainers about changes to fs/ioctl.c Günther Noack
2024-03-27 13:10 ` [PATCH v13 10/10] fs/ioctl: Add a comment to keep the logic in sync with the Landlock LSM Günther Noack
2024-03-28 12:11 ` Mickaël Salaün
2024-03-28 13:08 ` Paul Moore
2024-03-28 16:43 ` Mickaël Salaün
2024-03-28 17:06 ` Paul Moore
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=ZhBwstt0zakE4uN2@google.com \
--to=gnoack@google.com \
--cc=allenwebb@google.com \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=dtor@google.com \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=repnop@google.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.