content: Add attested build environments level requirements #1051
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -26,6 +26,7 @@ tracks without invalidating previous levels. | |||||||
| | [Build L1] | Provenance showing how the package was built | Mistakes, documentation | ||||||||
| | [Build L2] | Signed provenance, generated by a hosted build platform | Tampering after the build | ||||||||
| | [Build L3] | Hardened build platform | Tampering during the build | ||||||||
| | [Build L4] | Attested build environment | Tampering during the build via the build environment | ||||||||
|
|
||||||||
| <!-- For comparison: a future Build L4's focus might be reproducibility or | ||||||||
| hermeticity or completeness of provenance --> | ||||||||
|
|
@@ -231,14 +232,74 @@ All of [Build L2], plus: | |||||||
| </dl> | ||||||||
| </section> | ||||||||
|
|
||||||||
| <section id="build-l4"> | ||||||||
|
|
||||||||
| ### Build L4: Attested build environment | ||||||||
|
|
||||||||
| <dl class="as-table"> | ||||||||
| <dt>Summary<dd> | ||||||||
|
|
||||||||
| Compromising a build requires exploiting a vulnerability in the build | ||||||||
| platform's supply chain or physical access to the underlying compute | ||||||||
| platform. | ||||||||
|
|
||||||||
| In practice, this means that builds are configured to run on a build platform | ||||||||
| that supports hardware capabilities for attesting to the state of the | ||||||||
| compute environment executing builds. | ||||||||
|
|
||||||||
| <dt>Intended for<dd> | ||||||||
|
|
||||||||
| Software releases needing assurances about the integrity of the environment | ||||||||
| used to create the release (e.g., specific compute platform, pre-build | ||||||||
| tamper detection). | ||||||||
| Build L4 usually requires significant changes to existing build platforms. | ||||||||
|
|
||||||||
| <dt>Requirements<dd> | ||||||||
|
|
||||||||
| All of [Build L3], plus: | ||||||||
|
|
||||||||
| - Software producer: | ||||||||
| - MUST run builds on a hosted build platform that meets Build L4 | ||||||||
| requirements. | ||||||||
| - SHOULD verify the [build environment attestations] at the start of a | ||||||||
| build and produce a [verification summary] about the check. | ||||||||
|
|
||||||||
| - Build platform: | ||||||||
| - MUST generate and distribute attestations to good known integrity | ||||||||
| measurements of the entire initial state of the build environment | ||||||||
| (i.e., VM/container image, boot process and filesystem). All | ||||||||
| attestations MUST be authenticated by a hardware root of trust. | ||||||||
|
There was a problem hiding this comment. We may want to clarify "hardware" here. A vTPM is not "hardware" but is a software implementation of TPM that appears to the VM as if it were hardware. There was a problem hiding this comment. There's actually a note at the end of the requirements clarifying that virtual hardware also works. Do you think that's enough, or is it worth clarifying up front? |
||||||||
| - MUST capture all of the inputs to the build in the Provenance. | ||||||||
| - MUST verify the build environment integrity against the build | ||||||||
| environment attestations prior to passing control of the build to | ||||||||
|
There was a problem hiding this comment. When you say "prior to", do you mean that there is a separator event between boot to the build executor and the executor running any build request? That's my expectation, but this also seems like there could be a temporal prior, where an attestation verification service must do this verification before providing a ticket (for example) to permit the build request to proceed. I don't think the latter is desirable. See my later comment about response-time attestations. |
||||||||
| the tenant. | ||||||||
|
|
||||||||
| <dt>Benefits<dd> | ||||||||
|
There was a problem hiding this comment. An alternate framing would be that it removes almost all of the build platform from the root of trust. All that's left is the hardware vendor and physical access. There was a problem hiding this comment. At a high level, this is true, and we should probably keep this section more concise than it currently is. We did want to capture some of the nuance of doing this practice, though. For example, you actually need to still place a fair amount of trust in the cloud provider that's hosting the VMs running the builds to not tamper with components like the host OS or the vTPM implementation being used to check the integrity of the build environment. The other part we wanted to emphasize is the machine-checkable aspect of relying on the attestable hardware, compared to the expectations for verification at L3. Maybe this nuance doesn't need to be covered in such detail here? |
||||||||
|
|
||||||||
| All of [Build L3], plus: | ||||||||
|
|
||||||||
| - Greatly reduces trust in a hosted build platform by increasing | ||||||||
| observability into the level of integrity of the build environment. | ||||||||
| - Provides machine-checkable, cryptographic, hardware-rooted evidence | ||||||||
|
There was a problem hiding this comment. I know that "hardware-rooted" has been used a fair bit when describing confidential computing environments, but it is misleading and not representative of the desired property.
Suggested change
I'm not sure binding the specification to TCG as the only trustworthy industry standard body is required. |
||||||||
| about: | ||||||||
| - The initial state of the build environment executing a build, such | ||||||||
| as its VM/container image, boot process, kernel and filesystem. | ||||||||
| - The specific build environment that executed a build. | ||||||||
|
|
||||||||
| </dl> | ||||||||
| </section> | ||||||||
|
|
||||||||
| <!-- Link definitions --> | ||||||||
|
|
||||||||
| [build l0]: #build-l0 | ||||||||
| [build l1]: #build-l1 | ||||||||
| [build l2]: #build-l2 | ||||||||
| [build l3]: #build-l3 | ||||||||
| [build l4]: #build-l4 | ||||||||
| [build environment attestations]: requirements.md#hardware-attested | ||||||||
| [future versions]: future-directions.md | ||||||||
| [hosted]: requirements.md#isolation-strength | ||||||||
| [previous version]: ../v0.1/levels.md | ||||||||
| [provenance]: terminology.md | ||||||||
| [verification]: verifying-artifacts.md | ||||||||
| [verification summary]: verification_summary.md | ||||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -125,6 +125,39 @@ of build types](/provenance/v1#index-of-build-types). | |
|
|
||
| </details> | ||
|
|
||
| ### Build environment model | ||
|
|
||
| Following the [build model](#build-model), we model a *build environment* | ||
| as a single instance of an execution context that runs a tenant's build | ||
| on a hosted build platform. Specifically, a build environment comprises | ||
| resources from the *compute platform* and a *build image*. | ||
|
|
||
| A typical build environment will go through the following lifecycle: | ||
|
|
||
| 1. A hosted build platform creates different build images through a separate | ||
| build process. For SLSA Build L4, the build platform outputs provenance | ||
| describing this process. | ||
| 2. The hosted build platform deploys a build image on a compute platform to | ||
| provision a new build environment. For SLSA Build L4, the | ||
| build platform validates the *measurement* of the environment's | ||
| *boot process*. | ||
| 3. When a new *build request* is made, the platform assigns the request to | ||
| a deployed build environment. For SLSA Build L4, the tenant may validate | ||
| the measurement of the build environment. | ||
| 4. Finally, the *build executior* running within the environment executes | ||
| the tenant's build steps. | ||
|
|
||
| | Primary Term | Description | ||
| | --- | --- | ||
| | Build image | The run-time context within a build environment, such as the VM or container image. Individual components of a build image are provided by both the hosted build platform and tenant, and include the build executor, platform-provided pre-installed guest OS and packages, and the tenant’s build steps and external parameters. | ||
|
There was a problem hiding this comment. This definition of build image as including parts from a tenant seems contrary to prior uses of the term to mean specifically the image of the build environment. I would advise checking prior instances of "build image" and disambiguate them with "build environment image" and "tenant build image". A build platform will attest to itself, but it may also mount a container including a tenant's build toolchain for executing a build request, so that's an important distinction to make. |
||
| | Build executor | The platform-provided program dedicated to executing the tenant’s build definition, i.e., running the build, within the build image. | ||
|
There was a problem hiding this comment. Clarify that the build executor must be a measured component of the build environment image. |
||
| | Build request | The process of assigning a build to a pre-provisioned build environment on a hosted build process. | ||
|
There was a problem hiding this comment. I always think of requests as messages. Perhaps, "A user-provided message to the build platform that is used to assign a build to a pre-provisioned build environment on a hosted build process." But this could be splitting hairs. |
||
| | Compute platform | The compute system and infrastructure, i.e., the host system (hypervisor and/or OS) and hardware, underlying a build platform. In practice, the compute platform and the build platform may be managed by the same or distinct organizations. | ||
| | Boot process | In the context of builds, the process of loading and executing the layers of firmware and software needed to start up a build environment. | ||
| | Measurement | The cryptographic hash of some system state in the build environment, including software binaries, configuration, or initialized run-time data. Software layers that are commonly measured include the bootloader, kernel, and kernel cmdline. | ||
|
|
||
| TODO: Disambiguate similar terms (e.g., build job, build runner) | ||
|
|
||
| ### Package model | ||
|
|
||
| Software is distributed in identifiable units called <dfn>packages</dfn> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no prior examples to be able to assess the truthfulness of this statement. Significant changes could be required for any increased level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. It's true that L3 already has a very similar statement, and we still wanted to be explicit about the fact that this L4 would require additional significant changes on top of L3. We can be more precise in what we mean here: for example, one of the significant requirements is hardware with very particular features (e.g., TPM or TEE support). Would that be more helpful here?