Re: WIP: verity support for overlayfs

["Colin Walters" <walters@verbum.org>]

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/ )

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.