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. | ||||||||
|
There was a problem hiding this comment. How about:
Suggested change
and then list some of the requirements? |
||||||||
|
|
||||||||
| <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 | ||||||||
|
There was a problem hiding this comment. I'm worried that this definition precludes any sort of distributed build from ever meeting SLSA L4 - it seems to assume that a build is always hermetic within a single build environment, and so easily described as I'd have no objection to defining a SLSA framework for hermetic single-host builds, if that is independently useful, but for "L4" where the implicit assumption is that all high-trust builders should aim to achieve it, I'm not yet convinced that this is the correct successor to L3. Though even here, "trust of software" seems still necessary, in that I don't know how to go from a description of a build to a fully realized set of input files without already having to have trusted that some build platform software has interpreted it correctly. Perhaps the right target is a broadened version of the same: a chain of hardware-rooted build attestations to what software was running on each node leveraged in the build process, with that software in turn attesting what environment it set up locally, etc? This would make it easier to be "tamper evident" for hardware attacks, though still require trusting that the build platform software is sufficiently bug- and backdoor-free. Failing that, @TomHennen 's comment elsewhere about "independently reproducible" might be a better choice for L4. Though that may also fail on practicality grounds: I'm not sure of many systems that have ever achieved multi-party bitwise reproducibility (I don't think Debian is there yet?), and I don't know what that would look like for closed-source systems that only execute on one build platform in practice. There was a problem hiding this comment.
@EricBurnett I agree with this target (and I think it's consistent with the spirit - the build environment is potentially distributed). It would be a small change in the next line to make it more explicit - - (i.e., VM/container image, boot process and filesystem)
+ (i.e., VM/container image, boot process, and filesystem, for each host in 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? There was a problem hiding this comment. In a TEE featuring a vTPM there should still be a hardware root of trust. The vTPM would be linked to signed HW evidence, for by example by mixing a hash of the vTPMs AKpub into the report-data field of a TEE's attestation report. So, the original statement sounds fine to me. I assume a HW RoT is key and not something that can be supplanted by sw. There was a problem hiding this comment. I do wonder if there's a useful middle ground where vTPMs that aren't hardware backed can still provide meaningful value. If this level requires full hardware backed support would that be too big a step? There was a problem hiding this comment. I think another potential middle ground is a HSM where authentication requires certain authentication requirements (whether secure/measured boot, validating PCRs, some validated token, etc.)? There was a problem hiding this comment. In this case I'd explicitly state here that "software vTPMs" are valid too. sth like:
The latter would be referring to vTPMs that are provisioned by a cloud service provider on tenant VMs and for which you'd get a CSP-provided cert-chain to verify. |
||||||||
| - 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? There was a problem hiding this comment. I see the importance of capturing the nuance. I think what Mark might be getting at is that the benefits as currently enumerated are a bit abstract. E.g. "Greatly reduces trust in a hosted build platform by increasing observability into the level of integrity of the build environment." Could this instead be something like "Greatly reduces the TCB of a hosted build platform by preventing tampering with the build execution environment, leaving only the OS and vTPM in scope" or something like that? |
||||||||
|
|
||||||||
| 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 | ||||
|---|---|---|---|---|---|---|
|
|
@@ -32,35 +32,38 @@ build level, implementing any controls as specified by the chosen platform. | |||||
| <th>Implementer | ||||||
| <th>Requirement | ||||||
| <th>Degree | ||||||
| <th>L1<th>L2<th>L3<th>L4 | ||||||
marcelamelara marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| <tr> | ||||||
| <td rowspan=3><a href="#producer">Producer</a> | ||||||
| <td colspan=2><a href="#choose-an-appropriate-build-platform">Choose an appropriate build platform</a> | ||||||
| <td>✓<td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td colspan=2><a href="#follow-a-consistent-build-process">Follow a consistent build process</a> | ||||||
| <td>✓<td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td colspan=2><a href="#distribute-provenance">Distribute provenance</a> | ||||||
| <td>✓<td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td rowspan=6><a href="#build-platform">Build platform</a> | ||||||
| <td rowspan=3><a href="#provenance-generation">Provenance generation</a> | ||||||
| <td><a href="#provenance-exists">Exists</a> | ||||||
| <td>✓<td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td><a href="#provenance-authentic">Authentic</a> | ||||||
| <td> <td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td><a href="#provenance-unforgeable">Unforgeable</a> | ||||||
| <td> <td> <td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td rowspan=3><a href="#isolation-strength">Isolation strength</a> | ||||||
| <td><a href="#hosted">Hosted</a> | ||||||
| <td> <td>✓<td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td><a href="#isolated">Isolated</a> | ||||||
| <td> <td> <td>✓<td>✓ | ||||||
| <tr> | ||||||
| <td><a href="#hardware-attested">Hardware-Attested</a> | ||||||
| <td> <td> <td> <td>✓ | ||||||
| </table> | ||||||
|
|
||||||
| ### Security Best Practices | ||||||
|
|
@@ -153,7 +156,7 @@ minimum requirements on its: | |||||
| the build process? | ||||||
|
|
||||||
| <table> | ||||||
| <tr><th>Requirement<th>Description<th>L1<th>L2<th>L3<th>L4 | ||||||
|
|
||||||
| <tr id="provenance-exists"><td>Provenance Exists<td> | ||||||
|
|
||||||
|
|
@@ -182,7 +185,7 @@ Provenance. | |||||
| [SLSA Provenance]: provenance.md | ||||||
| [associated suite]: ../../attestation-model#recommended-suite | ||||||
|
|
||||||
| <td>✓<td>✓<td>✓<td>✓ | ||||||
| <tr id="provenance-authentic"><td>Provenance is Authentic<td> | ||||||
|
|
||||||
| *Authenticity:* Consumers MUST be able to validate the authenticity of the | ||||||
|
|
@@ -233,7 +236,7 @@ build platform (i.e. outside the trust boundary), except as noted below. | |||||
| the provenance. | ||||||
| - Completeness of resolved dependencies is best effort. | ||||||
|
|
||||||
| <td> <td>✓<td>✓<td>✓ | ||||||
| <tr id="provenance-unforgeable"><td>Provenance is Unforgeable<td> | ||||||
|
|
||||||
| *Accuracy:* Provenance MUST be strongly resistant to forgery by tenants. | ||||||
|
|
@@ -258,9 +261,11 @@ build platform (i.e. outside the trust boundary), except as noted below. | |||||
| Note: This requirement was called "non-falsifiable" in the initial | ||||||
| [draft version (v0.1)](../v0.1/requirements.md#non-falsifiable). | ||||||
|
|
||||||
| <td> <td> <td>✓<td>✓ | ||||||
| </table> | ||||||
|
|
||||||
| TODO: Add completeness of resolved dependencies | ||||||
|
|
||||||
| ### Isolation strength | ||||||
|
|
||||||
| [Isolation strength]: #isolation-strength | ||||||
|
|
@@ -270,12 +275,12 @@ The build platform is responsible for isolating between builds, even within the | |||||
| same tenant project. In other words, how strong of a guarantee do we have that | ||||||
| the build really executed correctly, without external influence? | ||||||
|
|
||||||
| The SLSA Build level describes the minimum bar for isolation strength. | ||||||
| For more information on assessing a build platform's isolation strength, | ||||||
| see [Verifying build platforms](verifying-systems.md). | ||||||
|
|
||||||
| <table> | ||||||
| <tr><th>Requirement<th>Description<th>L1<th>L2<th>L3<th>L4 | ||||||
|
|
||||||
| <tr id="hosted"> | ||||||
| <td>Hosted | ||||||
|
|
@@ -286,7 +291,7 @@ infrastructure, not on an individual's workstation. | |||||
|
|
||||||
| Examples: GitHub Actions, Google Cloud Build, Travis CI. | ||||||
|
|
||||||
| <td> <td>✓<td>✓<td>✓ | ||||||
| <tr id="isolated"> | ||||||
| <td>Isolated | ||||||
| <td> | ||||||
|
|
@@ -330,9 +335,77 @@ means that the build ran with no network access. Such a requirement requires | |||||
| substantial changes to both the build platform and each individual build, and is | ||||||
| considered in the [future directions](future-directions.md). | ||||||
|
|
||||||
| <td> <td> <td>✓<td>✓ | ||||||
| <tr id="hardware-attested"> | ||||||
| <td>Hardware-Attested | ||||||
| <td> | ||||||
|
|
||||||
| The build platform generated an authenticated attestation to the integrity | ||||||
|
There was a problem hiding this comment. That is, generating an in-toto attestation about the entire initial state of the build environment? We may run into confusion here between attestation and attestation:
from TCG Glossary, and
from SLSA Terminology It might be worth adding a note to clarify to readers who have familiarity with both terms. |
||||||
| of the entire initial state of the build environment (i.e., VM/container | ||||||
|
There was a problem hiding this comment. I think I would separate VM and container images. VM image should always be attested while the container image should be attested if containers are being used. Something like:
There was a problem hiding this comment. To clarify, you specifically mean the case where a container is used within a VM, right? My intent here was more to cover the scenario in which container-only build images are used. Whether or not containers are sufficient to achieve L3, I think is a related but separate question. |
||||||
| image, kernel, and filesystem) was generated at creation time and verified | ||||||
| at deployment time. The build platform also attested to the build request. | ||||||
| In other words, tampering with the initial state of the build environment | ||||||
| MUST be detectable by the platform itself and the build. | ||||||
|
There was a problem hiding this comment. "an the build."... executor? agent? |
||||||
|
|
||||||
| The build platform MUST guarantee the following: | ||||||
|
|
||||||
| - When creating a new build environment: | ||||||
marcelamelara marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| - The integrity of the build image (i.e., VM or container) MUST be | ||||||
| authenticated and verifiable. That is, SLSA Build L3+ Provenance for | ||||||
| the build image MUST be generated and distributed to allow for | ||||||
| independent verification. | ||||||
| - The boot process of each build environment MUST be measured and | ||||||
| attested using a [TCG-compliant measured boot] mechanism. In | ||||||
| addition, the initial state of the build environment's disk image | ||||||
|
There was a problem hiding this comment. There are reasons for the disk image to not be entirely measured, so this seems like it could be too coarse of a requirement. There are ways security-critical components of user space are measured. They go past the PCRs 0-7 in the TCG-compliant measured boot link. This whole disk integrity would disallow content-addressed build caches that already have SLSA attestations, such as what Bazel.build uses for performance. The fact of the matter is that we have bespoke ways of evaluating attestation evidence and specifying policy for their acceptance. There is no standard since OSes consider different things to be security-critical. Perhaps, "every file read from disk must be integrity-protected by some means traceable to the build environment identity or build request" There was a problem hiding this comment. I'll be closing this PR soon. Let's move this discussion to #1107 ! |
||||||
| MUST be integrity measured and attested. The boot and disk | ||||||
| attestations MUST be distributed to allow for independent | ||||||
| verification. | ||||||
| - When deploying a new build environment: | ||||||
|
There was a problem hiding this comment. Are these deployment assertions meant to be checkable from each of the build environment's output build attestations, or are these operational attestations for claiming SLSA L4? I can't really prove to folks that I did a check before starting the builder VM unless I'm already in a builder VM, which doesn't seem like the right scope. OR is this saying that the build image's SLSA provenance MUST be verified as a component of the DRTM's remote attestation for the built artifacts? Is delegating that verification to a VSA already understood as an acceptable verification? |
||||||
| - The build image's SLSA Provenance MUST be verified to ensure the | ||||||
| VM/container image has not been tampered with. | ||||||
| - The boot process and state of disk image attestations MUST be | ||||||
| verified to ensure the guest kernel and filesystem have not been | ||||||
| tampered with. | ||||||
| - A unique immutable build environment identifier (e.g., | ||||||
| cryptographic keypair) MUST be generated and cryptographically bound | ||||||
| to the build environment via attestation. This *deploy-time | ||||||
|
There was a problem hiding this comment. Is this item meant to address the Google doc comment of attestation verification policy-based key provisioning for SLSA L4 build attestation signing keys? If so, I think this could be clearer. I'm not familiar enough with SLSA mechanics to know whether SLSA level is expected to be assigned by a specific cryptographic key usage. |
||||||
| attestation* MUST be generated only after build image, boot process | ||||||
| and disk image integrity have been verified, and distributed to | ||||||
| allow for independent verification. | ||||||
| - When accepting a new build request (e.g., GHA build job): | ||||||
| - The build environment's deploy-time attestation and uniqueness of its | ||||||
|
There was a problem hiding this comment. What does this mean? I imagine that the SLSA L4 attestation signing key would be deleted from memory after use from a previous build job, so yes you'd need to re-establish the attestation with the key management service, but only AFTER the build request has completed. You don't want the key material in memory while an untrusted build process is taking place, even if it is isolated. Who does the build environment attestation verification? It seems like the build job is accepting itself from this wording. The build requester would not necessarily be the one with an appropriate attestation verification policy to apply before even initiating a build request, but maybe that's what you meant? Is a build request supposed to happen over an attested channel? |
||||||
| immutable identifier MUST be verified to ensure the initial state | ||||||
| of the build environment has not been tampered with. | ||||||
| - A unique immutable build identifier (e.g., GHA build job | ||||||
| ID) MUST be generated and cryptographically bound to the build | ||||||
| environment via attestation. This *request-time attestation* | ||||||
| MUST be generated only after the deploy-time attestation has been | ||||||
| verified, and distributed to allow for independent verification. | ||||||
| - Run-time changes to the build environment's disk image SHOULD be | ||||||
| observable at run-time by the executing build. These changes NEED NOT | ||||||
| be attested. | ||||||
| - Boot, disk, deploy- and request-time attestations MUST be authenticated | ||||||
|
There was a problem hiding this comment. I don't think request-time attestation is what's desirable. Although it could be an enhancement for tenant confidentiality, i.e., "I don't want to release my code to a builder I haven't vetted." |
||||||
| by a hardware root of trust (e.g., [TPM] or [trusted execution | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| environment]). In addition, these attestations MUST be distributed in a | ||||||
| consistent format that follows the SLSA [attestation model], such as | ||||||
| [SCAI]. | ||||||
|
|
||||||
| NOTE: Virtual hardware (e.g., vTPM) MAY be used to meet this requirement. | ||||||
|
|
||||||
| NOTE: A [confidential computing] technology MAY be used to meet this | ||||||
| requirement. Such technologies SHOULD be chosen for builds with a need for | ||||||
| additional data and code confidentiality, and tamper-evidence properties | ||||||
| during build execution. | ||||||
|
|
||||||
| <td> <td> <td> <td>✓ | ||||||
| </table> | ||||||
|
|
||||||
| [attestation model]: attestation-model.md#model-and-terminology | ||||||
| [confidential computing]: https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/Common-Terminology-for-Confidential-Computing.pdf | ||||||
| [external parameters]: provenance.md#externalParameters | ||||||
| [identified in the provenance]: provenance.md#model | ||||||
| [package ecosystem]: verifying-artifacts.md#package-ecosystem | ||||||
| [SCAI]: https://github.com/in-toto/attestation/blob/main/spec/predicates/scai.md | ||||||
| [TCG-compliant measured boot]: https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/ | ||||||
| [TPM]: https://trustedcomputinggroup.org/resource/tpm-library-specification/ | ||||||
| [trusted execution environment]: https://csrc.nist.gov/glossary/term/trusted_execution_environment | ||||||
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?
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.
I'm sympathetic to view that we can just repeat the language from L3 (unless we also want to rewrite the L3 'intended for' section). Maybe with the caveat "significant changes to existing L3 builds platforms"?
I think the requirements below do a fine job of getting into the details.