From: Jeff Xu <jeffxu@chromium.org>
To: "Günther Noack" <gnoack@google.com>
Cc: linux-security-module@vger.kernel.org,
"Mickaël Salaün" <mic@digikod.net>, "Jeff Xu" <jeffxu@google.com>,
"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
Subject: Re: [PATCH v7 9/9] landlock: Document IOCTL support
Date: Fri, 8 Dec 2023 13:58:00 -0800 [thread overview]
Message-ID: <CABi2SkXoJN6tEaM_=kKPQVmQ3+xROkNGb0XotwM9xSyTZr1FGA@mail.gmail.com> (raw)
In-Reply-To: <ZXMQdqeGH6i5aJd8@google.com>
On Fri, Dec 8, 2023 at 4:48 AM Günther Noack <gnoack@google.com> wrote:
>
> Hello Jeff!
>
> On Fri, Dec 01, 2023 at 11:55:03AM -0800, Jeff Xu wrote:
> > On Fri, Dec 1, 2023 at 6:41 AM Günther Noack <gnoack@google.com> wrote:
> > > +Rights associated with file descriptors
> > > +---------------------------------------
> > > +
> > > +When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` and
> > > +``LANDLOCK_ACCESS_FS_IOCTL`` rights is associated with the newly created file
> > > +descriptor and will be used for subsequent truncation and ioctl attempts using
> > > +:manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar to
> > > +opening a file for reading or writing, where permissions are checked during
> > > +:manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and
> > > :manpage:`write(2)` calls.
> > >
> > > -As a consequence, it is possible to have multiple open file descriptors for the
> > > -same file, where one grants the right to truncate the file and the other does
> > > -not. It is also possible to pass such file descriptors between processes,
> > > -keeping their Landlock properties, even when these processes do not have an
> > > -enforced Landlock ruleset.
> > > +As a consequence, it is possible to have multiple open file descriptors
> > > +referring to the same file, where one grants the truncate or ioctl right and the
> > > +other does not. It is also possible to pass such file descriptors between
> > > +processes, keeping their Landlock properties, even when these processes do not
> > > +have an enforced Landlock ruleset.
> > >
> > I understand the "passing fd between process ", but not the " multiple
> > open fds referring to the same file, with different permission", are
> > those fds all opened within the same domain ?
> >
> > Can we have a pseudocode to help understanding ?
>
> It's a little bit expanding the scope here, as the documentation existed alredy
> prior to the patch set, but it's a fair comment that this paragraph is not clear
> enough. I tried to rephrase it. Maybe this is better:
>
> As a consequence, it is possible that a process has multiple open file
> descriptors referring to the same file, but Landlock enforces different things
> when operating with these file descriptors. This can happen when a Landlock
> ruleset gets enforced and the process keeps file descriptors which were opened
> both before and after the enforcement. It is also possible to pass such file
> descriptors between processes, keeping their Landlock properties, even when
> some of the involved processes do not have an enforced Landlock ruleset.
>
> Some example code to clarify:
>
> One way that this can happen is:
>
> (1) fd1 = open("foobar.txt", O_RDWR)
> (2) enforce_landlock(forbid all ioctls)
> (3) fd2 = open("foobar.txt", O_RDWR)
>
> ==> You now have fd1 and fd2 referring to the same file on disk,
> but you can only do ioctls on it through fd1, but not through fd2.
>
> Or, using SCM_RIGHTS (unix(7)):
>
> (1) Process 1: Listen on Unix socket
> (2) Process 2: Enforce Landlock so that ioctls are forbidden
> (3) Process 2: fd = open("foobar.txt", O_RDWR)
> (4) Process 2: send fd to Process 1
> (5) Process 1: receive fd
>
> ==> Process 1 can not do ioctls on the received fd,
> as configured by the Landlock policy enforced in Process 2
>
> Or, simply by inheriting file descriptors through execve:
>
> (1) Parent process/main thread: Spawn thread t
> (t.1) Enforce Landlock so that ioctls are forbidden
> (This policy is local to the thread)
> (t.2) fd = open("foobar.txt", O_RDWR)
> (2) Parent process/main thread: join (exit) thread t
> (3) Parent process/main thread: execve and inherit fd!
>
> ==> The child process can not use ioctls with the inherited fd,
> as configured by the Landlock policy before
>
> The same is also possible with the truncation right.
>
Very helpful. Thanks!
-Jeff
> —Günther
prev parent reply other threads:[~2023-12-08 21:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 14:30 [PATCH v7 0/9] Landlock: IOCTL support Günther Noack
2023-12-01 14:30 ` [PATCH v7 1/9] landlock: Remove remaining "inline" modifiers in .c files Günther Noack
2023-12-01 14:30 ` [PATCH v7 2/9] selftests/landlock: Rename "permitted" to "allowed" in ftruncate tests Günther Noack
2023-12-01 14:30 ` [PATCH v7 3/9] landlock: Optimize the number of calls to get_access_mask slightly Günther Noack
2023-12-01 14:30 ` [PATCH v7 4/9] landlock: Add IOCTL access right Günther Noack
2023-12-01 19:51 ` Jeff Xu
2023-12-08 10:20 ` Günther Noack
2023-12-08 20:48 ` Jeff Xu
2023-12-01 14:30 ` [PATCH v7 5/9] selftests/landlock: Test IOCTL support Günther Noack
2023-12-01 14:30 ` [PATCH v7 6/9] selftests/landlock: Test IOCTL with memfds Günther Noack
2023-12-01 14:30 ` [PATCH v7 7/9] selftests/landlock: Test ioctl(2) and ftruncate(2) with open(O_PATH) Günther Noack
2023-12-01 14:30 ` [PATCH v7 8/9] samples/landlock: Add support for LANDLOCK_ACCESS_FS_IOCTL Günther Noack
2023-12-01 14:30 ` [PATCH v7 9/9] landlock: Document IOCTL support Günther Noack
2023-12-01 19:55 ` Jeff Xu
2023-12-08 12:47 ` Günther Noack
2023-12-08 21:58 ` Jeff Xu [this message]
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='CABi2SkXoJN6tEaM_=kKPQVmQ3+xROkNGb0XotwM9xSyTZr1FGA@mail.gmail.com' \
--to=jeffxu@chromium.org \
--cc=allenwebb@google.com \
--cc=dtor@google.com \
--cc=gnoack@google.com \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).