Re: WIP: verity support for overlayfs

[Alexander Larsson <alexl@redhat.com>]

On Thu, Mar 9, 2023 at 4:26 PM Colin Walters <walters@verbum.org> wrote:
>
>
>
> On Thu, Mar 9, 2023, at 9:59 AM, Miklos Szeredi wrote:
> > On Wed, 8 Mar 2023 at 16:29, Alexander Larsson <alexl@redhat.com> wrote:
> >>
> >> As was recently discussed in the various threads about composefs we
> >> want the ability to specify a fs-verity digest for metacopy files,
> >> such that the lower file used for the data is guaranteed to have the
> >> specified digest.
> >>
> >> I wrote an initial version of this here:
> >>
> >>   https://github.com/alexlarsson/linux/tree/overlay-verity
> >>
> >> I would like some feedback on this approach. Does it make sense?
> >>
> >> For context, here is the main commit text:
> >>
> >> This adds support for a new overlay xattr "overlay.verity", which
> >> contains a fs-verity digest. This is used for metacopy files, and
> >> whenever the lowerdata file is accessed overlayfs can verify that
> >> the data file fs-verity digest matches the expected one.
> >>
> >> By default this is ignored, but if the mount option "verity_policy" is
> >> set to "validate" or "require", then all accesses validate any
> >> specified digest. If you use "require" it additionally fails to access
> >> metacopy file if the verity xattr is missing.
> >>
> >> The digest is validated during ovl_open() as well as when the lower file
> >> is copied up. Additionally the overlay.verity xattr is copied to the
> >> upper file during a metacopy operation, in order to later do the validation
> >> of the digest when the copy-up happens.
> >
> > Hmm, so what exactly happens if the file is copied up and then
> > modified?  The verification will fail, no?
>
> I believe the intention here is to deploy this without a writable upper dir by default, so there's no copy-up, the calling code just gets -EROFS.  The intention is to also use this to push the podman/docker/kube style ecosystem away from "mutable by default" container images i.e. to "readonlyRootFilesystem" by default (xref https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ )

That is indeed some of the primary usecases for this. However, that
doesn't mean it is not useful also for other usecases.

> But yes, some scenarios will still want a writable upper dir for default, as long as that writable upper dir is discarded across reboots (to aid in anti-persistence).  Maybe this needs to be configurable; I could imagine people wanting a writable upper dir, but to still enforce fs-verity for *existing* content.  Other cases may want the logic to just strip away the fsverity xattr across copy-up in this case.

I've been chatting with amir in github about this, and yes, we can
have options that make this useful also with an upper. I'll try to
post a new version with this tomorrow.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl@redhat.com         alexander.larsson@gmail.com