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"? 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).
The second sentence above relates to this case:
* A lower dir file "lower/a" does not have fsverity enabled.
* Someone does "chown mnt/a"
* This causes overlayfs to make a "copy up" operation of the "lower/a"
to "upper/a"
* But, we can't use the optimized "copy metacopy only" version of
"copy up", because we could then not specify a digest xattr on the new
file, so we copy the content of "lower/a" to "upper/a".
What exactly is your worry in this case?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
