Re: SVSM initiated early attestation / guest secrets injection

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jan 20, 2023 at 07:39:30AM -0500, James Bottomley wrote:
> On Fri, 2023-01-20 at 08:57 +0000, Daniel P. Berrangé wrote:
> > On Fri, Jan 20, 2023 at 09:37:35AM +0100, Jörg Rödel wrote:
> > > On Thu, Jan 19, 2023 at 04:29:23PM -0500, James Bottomley wrote:
> > > > How can they stay there?  Even if the SVSM is the point of first
> > > > contact to receive the secret, it must give the secret to higher
> > > > VMPLs
> > > > to try the mount, so the higher VMPLs have to destroy the secret
> > > > they
> > > > were given on failure.
> > > 
> > > My thinking was that the SVSM will only hand out the secrets once
> > > the
> > > code in higher VMPLs has proven itself to be trusted. But it is
> > > possible
> > > for an attacker to create an image with the expected parts to get
> > > the
> > > measurements right and then use a fall-back mount if decryption
> > > fails to
> > > steal the secret.
> > 
> > With a vTPM, and systemd-pcrphase.service, it is possible to seal
> > secrets to prevent such an attack, by including phase=initrd in
> > the sealing PCRs. IOW, nothing after the initrd can unseal the
> > secrets, even if a different filesystem mount was substituted.
> > 
> > Secrets that are needed /after/ the root FS is mounted (eg SSH
> > host key, Apache HTTP certs) can be sealed with a PCR set that
> > covers the LUKS master key hash, so that they can only be acccessed
> > if the correct rootfs was unlocked.
> 
> But that provides no additional security: the LUKS master hash is just
> a hash of an area on the disk which anyone controlling the device can
> see.  I can duplicate this area and still substitute my own volume
> (which would still fail to decrypt when presented with the key), so the
> trusted mounting component sill has to correctly handle the failure
> case.

Yes, it would have to be a hash that is different from the
hash that's exposed in clear text in the LUKS header. For
example it could be hash(master_key || uuid). 


> > In the vTPM case, the guest owner is deciding policy when they
> > seal secrets to the vTPM during guest provisioning initially.
> > If we try to support a scenario without a vTPM, then the guest
> > owner has to determine policy by using a carefully built initrd
> > that does not do any fallbacks, and they have to rely on having
> > a known firmware with a particular set to certs enrolled, which
> > has support implications for public clouds. Much less flexible.
> >  
> > > But such mount fallbacks a generally a bad idea in a CVM.
> > 
> > Yep, but hopefully not fatal, if the user picks a suitable set
> > of PCRs for sealing data.
> 
> You can't rely only on PCRs for this because they don't contain enough
> information, you must code the correct policy into the trusted mount
> component as well.

Well it entirely depends on what info is being measured into the
PCRs. If what systemd measures into PCRs in the initrd is not
sufficient to allow safe sealing policies, we can request further
info.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|