Re: Official cloud image requirements

[Noah Meyerhans <noahm@debian.org>]

On Sat, Jun 06, 2020 at 08:28:30PM +0900, Charles Plessy wrote:
> > AFAIK there is general consensus amongst us that we want the cloud
> > images to be built on the Debian infrastructure, not on the cloud
> > provider infrastructure.
> 
> just for the record, here is what you added:
> 
> * '''E. all cloud-related images have to be built on Debian
>   infrastructure''' (for instance Salsa, Casulana, Patterson machines).
>   This is to avoid risks that some cloud providers might injects their
>   code.

I'm not a fan of that language.  It puts us well into the tinfoil-hat
realm, and ignores the reality of cloud adoption across a wide variety
of industries, many of which have very significant security
requirements.

> I do not oppose the requirement, but I have a long-standing question
> that I asked when we were criticised for building Amazon images on the
> Amazon cloud, and that was never answered:
> 
>  -> When a cloud provider can inject some code at build time, isn't it
>  as easy for it to inject the code at run time, or to instance virtual
>  machines with a tampered images while pretending to use the official
>  one ?

Yes.

But a cloud provider isn't going to do that, because doing covertly
would risk such a blow to customer trust that it would do very
significant financial damage to the cloud provider and to the cloud
computing industry as a whole.  Whatever benefit the cloud provider
thinks they'd gain from this is outweighed by this risk.

IMO, as somebody who fought against this requirement and who still
generally disagrees with it, here are the primary reasons I see for
Debian to have this requirement:

1. Security, not from cloud providers themselves, but from other cloud
customers via sidechannel attacks such as meltdown.  The risk is small,
but IMO greater than the risk of the cloud provider itself doing
anything nefarious.  (Keep in mind that all major cloud providers have
taken sophisticated steps to mitigate this class of risks at the
hypervisor level, above & beyond what's already in Xen, KVM, etc,
possibly implemented in custom hardware.)

2. Neutrality.  Debian could build images on a single cloud service, but
that might be seen by some as an endorsement of that service.  By
building the images "in-house", we avoid such perception.  We could
mitigate this concern by building images for a given provider on that
provider's service, but that just adds complexity and is not worth the
effort.

noah