On Mon, May 15, 2023 at 8:00 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> On Mon, May 15, 2023 at 07:44:13AM +0200, Alexander Larsson wrote:
> > On Sun, May 14, 2023 at 9:22 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > >
> > > On Wed, May 03, 2023 at 10:51:37AM +0200, Alexander Larsson wrote:
> > > > +- "require":
> > > > + Same as "on", but additionally all metacopy files must specify a
> > > > + verity xattr. This means metadata copy up will only be used if
> > > > + the data file has fs-verity enabled, otherwise a full copy-up is
> > > > + used.
> > >
> > > The second sentence makes it sound like an attacker can inject arbitrary data
> > > just by replacing a data file with one that doesn't have fsverity enabled.
> > >
> > > I really hope that's not the case?
> > >
> > > I *think* there is a subtlety here involving "metacopy files" that were created
> > > ahead of time by the user, vs. being generated by overlayfs. But it's not
> > > really explained.
> >
> > I'm not sure what you mean here? When you say "replacing a data file",
> > do you mean "changing the content of the lowerdir"?
>
> Yes. Specifically the data-only lowerdir.
>
> > Because if you can just change lowerdir content then you can make users of the
> > overlayfs mount read whatever data you want (independent of metacopy or any of
> > this).
>
> But isn't preventing that the whole point of your feature?
>
> What am I missing?
If by "your feature", you mean the full composefs idea, then things
are different. In this case the root mount is an overlayfs with two
lowerdirs and no upper. The uppermost lower is a read-only erofs mount
with metadata and overlay xattrs for all files, and the lowermost one
is a data-only dir. You cannot modify the uppermost layer (since it's
a fsverity readonly erofs file). If you modify a data-only file it
will be detected at validation, because it can only be reached from
redirects in the image file, and we ensured all image files specified
a digest. There is no upper dir, so the overlayfs mount itself is not
writable, and thus there can be any meta-copy-up operations triggered
at all.
However, even if you had an upper dir ("writable composefs" usecase) I
don't see a problem. If you trigger a full (i.e. non-metadata) copy-up
then the copy-up operation itself will validate the data from the
lower at copy time (due to the verity xattr on the "middle layer").
I think again there is some confusion due to the two kinds of usecases
for the verity support. The basic usecase is just for general
robustness. I.e it allows the kernel to record information about the
original state of the content file when generating a metacopy
reference to it. If you later accidentally mount the overlayfs against
the wrong lower version you will get told about it. The second usecase
is the tamper proofing image case (composefs), and its security
depends on more details (i.e. the readonly image part and its
construction).
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
