linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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