From: Eric Biggers <ebiggers@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Alexander Larsson <alexl@redhat.com>,
miklos@szeredi.hu, linux-unionfs@vger.kernel.org, tytso@mit.edu,
fsverity@lists.linux.dev
Subject: Re: [PATCH v3 2/4] ovl: Add framework for verity support
Date: Tue, 13 Jun 2023 11:22:33 -0700 [thread overview]
Message-ID: <20230613182233.GC1139@sol.localdomain> (raw)
In-Reply-To: <CAOQ4uxg6BD_RDtWob5q2eX6uQ5hcWrK7wEDcBhFVrGM3vsn=NA@mail.gmail.com>
On Tue, Jun 13, 2023 at 12:34:10PM +0300, Amir Goldstein wrote:
> >
> > In general the proposed documentation reads like the audience is overlayfs
> > developers.
>
> I never considered that overlayfs.rst is for an audience other than
> overlayfs developers or people that want to become overlayfs
> developers. It is not a user guide. If it were, it would have been a
> very bad one.
>
> > It doesn't describe the motivation for the feature or how to use it
> > in each of the two use cases. Maybe that is intended, but it's not what I had
> > expected to see.
> >
>
> Yeh, that's a valid point.
> That is what I wanted to know - what exactly is missing.
> I guess this is the documented motivation:
Sure, but even if the document is just for kernel developers, it should still
describe motivation and use cases, as those are important for userstanding.
> "This may then be used to verify the content of the source file at the time
> the file is opened"
>
> but it does not tell a complete chain of trust story.
>
> How about something along the lines of:
>
> "In the case that the upper layer can be trusted not to be tampered
> with while overlayfs is offline
So *online* tampering of the upper layer is fine?
> and some of the lower layers cannot
> be trusted not to be tampered with, the "verity" feature can protect
> against offline modification to lower files
Data of lower files, not simply "lower files", right?
Are *online* modifications to lower files indeed not in scope?
If the feature "can protect", then under what circumstances does it protect, and
under what circumstances what does it not protect?
It would also be helpful to explain what specifically is meant by "protect".
Does it mean that overlayfs prevents modifications to lower file data, or does
it mean that overlayfs detects modifications to lower file data after they
happen? If the latter, what happens when overlayfs detects a modification?
What do userspace programs experience?
> , whose metadata has been
> copied up to the upper layer (a.k.a "metacopy" files) ...."
>
> It's generic language that what the patches do, regardless of the
> trust model of composefs and how it composes an overlayfs layers.
It's better, but it could use some more detail. See my comments above.
- Eric
next prev parent reply other threads:[~2023-06-13 18:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 10:27 [PATCH v3 0/4] ovl: Add support for fs-verity checking of lowerdata Alexander Larsson
2023-06-12 10:27 ` [PATCH v3 1/4] fsverity: Export fsverity_get_digest Alexander Larsson
2023-06-12 10:27 ` [PATCH v3 2/4] ovl: Add framework for verity support Alexander Larsson
2023-06-12 16:32 ` Eric Biggers
2023-06-13 5:18 ` Amir Goldstein
2023-06-13 6:37 ` Eric Biggers
2023-06-13 8:08 ` Alexander Larsson
2023-06-13 9:34 ` Amir Goldstein
2023-06-13 18:22 ` Eric Biggers [this message]
2023-06-14 5:24 ` Amir Goldstein
2023-06-14 7:57 ` Alexander Larsson
2023-06-15 23:52 ` Eric Biggers
2023-06-16 8:11 ` Alexander Larsson
2023-06-17 19:47 ` Eric Biggers
2023-06-19 7:58 ` Alexander Larsson
2023-06-12 10:27 ` [PATCH v3 3/4] ovl: Validate verity xattr when resolving lowerdata Alexander Larsson
2023-06-12 10:28 ` Alexander Larsson
2023-06-12 19:09 ` Eric Biggers
2023-06-13 11:41 ` Alexander Larsson
2023-06-13 17:57 ` Eric Biggers
2023-06-14 3:28 ` Eric Biggers
2023-06-14 5:39 ` Amir Goldstein
2023-06-14 7:19 ` Alexander Larsson
2023-06-12 10:28 ` [PATCH v3 4/4] ovl: Handle verity during copy-up Alexander Larsson
2023-06-12 10:52 ` Amir Goldstein
2023-06-12 10:54 ` [PATCH v3 0/4] ovl: Add support for fs-verity checking of lowerdata Amir Goldstein
2023-06-12 11:09 ` Alexander Larsson
2023-06-12 14:53 ` Alexander Larsson
2023-06-12 15:05 ` Amir Goldstein
2023-06-14 6:14 ` Amir Goldstein
2023-06-14 7:07 ` Eric Biggers
2023-06-14 7:16 ` Alexander Larsson
2023-06-22 9:36 ` Amir Goldstein
2023-06-22 9:51 ` Alexander Larsson
2023-06-22 11:45 ` Amir Goldstein
2023-06-26 13:01 ` Amir Goldstein
2023-07-03 8:11 ` Alexander Larsson
2023-07-06 7:10 ` Amir Goldstein
2023-07-06 7:50 ` Alexander Larsson
2023-06-22 16:12 ` Eric Biggers
2023-06-22 18:07 ` Amir Goldstein
2023-06-13 13:57 ` Alexander Larsson
2023-06-13 17:59 ` Eric Biggers
2023-06-14 7:15 ` Alexander Larsson
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=20230613182233.GC1139@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=alexl@redhat.com \
--cc=amir73il@gmail.com \
--cc=fsverity@lists.linux.dev \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
/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