On Wed, Jun 14, 2023 at 7:24 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Tue, Jun 13, 2023 at 9:22 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> >
> > 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?
>
> No, for the sake of this section, it would be easier to say
> that upper is completely trusted and completely under our
> control and that the feature only hardens overlayfs when
> lower is not under our full control.
>
> In the case of composefs it's actually two lower layers, one trusted
> and one not trusted (and an optional trusted upper), but it does not
> matter IMO for the sake of explaining the basic feature.
>
> >
> > > 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?
>
> Right.
>
> >
> > Are *online* modifications to lower files indeed not in scope?
>
> They are. doc should not mention online.
>
> >
> > 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.
> >
>
> Fair enough.
>
> Alex,
>
> Please incorporate Eric's feedback above to come up with a more
> detailed description than:
>
> +This can be useful as a way to validate that a lower directory matches
> +the correct upper when it is re-mounted later. In case you can
> +guarantee that a overlayfs directory with verity xattrs is not
> +tampered with (for example using dm-verity or fs-verity) this can even
> +be used to guarantee the validity of an untrusted lower directory.
> +
>
> On the specific points that Eric mentioned.
I think maybe it's best we hash this out here first.
What do you think about this version:
fs-verity support
----------------------
During metadata copy up of a lower file, if the source file has
fs-verity enabled and overlay verity support is enabled, then the
"trusted.overlay.verity" xattr is set on the new metacopy file. This
specifies the expected fs-verity digest of the lowerdata file, which is
used to verify the content of the lower file at the time the metacopy
file is opened.
When a layer containing verity xattrs is used, it means that any
such metacopy file in the upper layer is guaranteed to match the
content that was in the lower at the time of the copy-up. If at any time
(during a mount, after a remount, etc) such a file in the lower is
replaced or modified in any way, then opening the corresponding file on
overlayfs will result in EIO and a detailed error printed to the kernel logs.
(Actually, due to caching the overlayfs mount might still see the previous
file contents after a lower file is replaced under an active mount, but
it will never see the wrong data.)
Verity can be used as a general robustness check to detect accidental
changes in the overlayfs directories in use. But, with additional care
it can also give more powerful guarantees. For example, if the upper layer
is fully trusted (by using dm-verity or something similar), then an untrusted
lower layer can be used to supply validated file content for all metacopy files.
If additionally the untrusted lower directories are specified as "Data-only",
then they can only supply such file content, and the entire mount can be
trusted to match the upper layer.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
