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 18:22:52 +0200 [thread overview]
Message-ID: <ZhAlXB3PWC4yyU8F@google.com> (raw)
In-Reply-To: <ZhAkDW2u3GItsody@google.com>
On Fri, Apr 05, 2024 at 06:17:17PM +0200, Günther Noack wrote:
> On Wed, Apr 03, 2024 at 01:15:45PM +0200, Mickaël Salaün wrote:
> > On Tue, Apr 02, 2024 at 08:28:49PM +0200, Günther Noack wrote:
> > > Can you please clarify how you make up your mind about what should be permitted
> > > and what should not? I have trouble understanding the rationale for the changes
> > > that you asked for below, apart from the points that they are harmless and that
> > > the return codes should be consistent.
> >
> > The rationale is the same: all IOCTL commands that are not
> > passed/specific to character or block devices (i.e. IOCTLs defined in
> > fs/ioctl.c) are allowed. vfs_masked_device_ioctl() returns true if the
> > IOCTL command is not passed to the related device driver but handled by
> > fs/ioctl.c instead (i.e. handled by the VFS layer).
>
> Thanks for clarifying -- this makes more sense now. I traced the cases with
> -ENOIOCTLCMD through the code more thoroughly and it is more aligned now with
> what you implemented before. The places where I ended up implementing it
> differently to your vfs_masked_device_ioctl() patch are:
>
> * Do not blanket-permit FS_IOC_{GET,SET}{FLAGS,XATTR}.
> They fall back to the device implementation.
>
> * FS_IOC_GETUUID and FS_IOC_GETFSSYSFSPATH are now handled.
> These return -ENOIOCTLCMD from do_vfs_ioctl(), so they do fall back to the
> handlers in struct file_operations, so we can not permit these either.
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.)
Thanks,
—Günther
next prev parent reply other threads:[~2024-04-05 16:22 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 [this message]
2024-04-05 18:04 ` Mickaël Salaün
2024-04-05 18:17 ` Kent Overstreet
2024-04-05 21:44 ` Günther Noack
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=ZhAlXB3PWC4yyU8F@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.