From 9d6feb16bb6d95007753189271c66588db4a0f4e Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Thu, 2 May 2024 15:55:42 -0700 Subject: [PATCH 1/9] First draft of HW attested build environment (new L4) requirements Signed-off-by: Marcela Melara --- docs/spec/v1.1/levels.md | 97 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 98bce5869..8d0c7ed40 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -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 before the build @@ -231,12 +232,108 @@ All of [Build L2], plus: +
+ +### Build L4: Attested build environment + +
+
Summary
+ +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 attestesting to the state of the +compute environment executing builds. + +
Intended for
+ +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. + +
Requirements
+ +All of [Build L3], plus: + +- Software producer: + - MUST run builds on a hosted build platform that meets Build L4 + requirements. + - SHOULD verify the build platform's attestations prior to a build and + produce a [VSA]() about the check. + +- Build platform: + - Each build image (i.e., VM or container) made available to software + producers MUST be built on a SLSA Build L3+ platform. The generated + SLSA Provenance MUST be distributed to allow for independent + verification. + - Distribution of SLSA Provenance for pre-installed software within the + build image MAY be best-effort. + - The boot process of each build environment MUST be measured and + attested using a [TCG-compliant Measured Boot]() mechanism. The + attestation MUST be authenticated and distributed for independent + verification. + - The initial state of the build environment's disk image MUST be + integrity measured and attested. The attestation MUST be + authenticated and distributed for independent verification. + - Read-write block devices or file system paths MUST be encrypted + with a key that is only accessible within the build image. + - Before launching a new environment based on a build image (i.e., VM + or container instance), its SLSA Provenance MUST be verified. + - Before making a build environment available for a build request: + - The boot process and state of disk image MUST be verified, and + cryptographically bound to the build image's valid SLSA provenance + to establish a verifiable integrity chain between a build image and + a build environment. + - A unique immutable build environment identifier (e.g., + cryptographic keypair) MUST be generated and cryptographically bound + to the build environment's integrity chain. + - These bindings MUST be authenticated and distributed for + independent verification. + - Before executing a tenant's build request (e.g., GHA build job): + - The build environment's integrity chain and uniqueness of its + immutable identifier MUST be verified. + - A unique immutable build request identifier (e.g., GHA build job + ID) MUST be generated and cryptographically bound to a valid build + environment integrity chain. + - All build platform generated attestations and cryptographic bindings + MUST be backed by a hardware root of trust (e.g., [TPM]() or [trusted + execution environment]()). Note: Virtual hardware (e.g., vTPM) MAY be + used to meet this requirement. + - Runtime changes to the build environment's disk image SHOULD be + observable at runtime by the executing build requst. + +
Benefits
+ +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 information about the build image’s provenance + beyond self-attestation by the build platform operator. +- Provides cryptographic, hardware-rooted evidence about: + - The initial state of the compute environment executing a build, such + as its boot settings (e.g., secure boot enabled), the bootloader and + kernel image. + - The initial state of the environment's disk image and its + configuration. + - The build environment that executed a particular run of a build. +- The use of [confidential computing technologies]() to meet these + requirements provides builds with additional data and code + confidentiality and tamper-evidence properties during build execution. + +
+
+ [build l0]: #build-l0 [build l1]: #build-l1 [build l2]: #build-l2 [build l3]: #build-l3 +[build l4]: #build-l4 [future versions]: future-directions.md [hosted]: requirements.md#isolation-strength [previous version]: ../v0.1/levels.md From 42e44070414202bee536bdbbca1a3a65cd733dde Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Fri, 3 May 2024 15:20:23 -0700 Subject: [PATCH 2/9] Add links to levels Signed-off-by: Marcela Melara --- docs/spec/v1.1/levels.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 8d0c7ed40..02efa3b51 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -262,7 +262,7 @@ All of [Build L3], plus: - MUST run builds on a hosted build platform that meets Build L4 requirements. - SHOULD verify the build platform's attestations prior to a build and - produce a [VSA]() about the check. + produce a [verification summary] about the check. - Build platform: - Each build image (i.e., VM or container) made available to software @@ -272,7 +272,7 @@ All of [Build L3], plus: - Distribution of SLSA Provenance for pre-installed software within the build image MAY be best-effort. - The boot process of each build environment MUST be measured and - attested using a [TCG-compliant Measured Boot]() mechanism. The + attested using a [TCG-compliant measured boot] mechanism. The attestation MUST be authenticated and distributed for independent verification. - The initial state of the build environment's disk image MUST be @@ -299,11 +299,11 @@ All of [Build L3], plus: ID) MUST be generated and cryptographically bound to a valid build environment integrity chain. - All build platform generated attestations and cryptographic bindings - MUST be backed by a hardware root of trust (e.g., [TPM]() or [trusted - execution environment]()). Note: Virtual hardware (e.g., vTPM) MAY be + MUST be backed by a hardware root of trust (e.g., [TPM] or [trusted + execution environment]). Note: Virtual hardware (e.g., vTPM) MAY be used to meet this requirement. - Runtime changes to the build environment's disk image SHOULD be - observable at runtime by the executing build requst. + observable at runtime by the executing build request.
Benefits
@@ -315,12 +315,12 @@ All of [Build L3], plus: beyond self-attestation by the build platform operator. - Provides cryptographic, hardware-rooted evidence about: - The initial state of the compute environment executing a build, such - as its boot settings (e.g., secure boot enabled), the bootloader and + as its boot settings (e.g., measured boot enabled), the bootloader and kernel image. - The initial state of the environment's disk image and its configuration. - The build environment that executed a particular run of a build. -- The use of [confidential computing technologies]() to meet these +- The use of [confidential computing] to meet these requirements provides builds with additional data and code confidentiality and tamper-evidence properties during build execution. @@ -334,8 +334,13 @@ All of [Build L3], plus: [build l2]: #build-l2 [build l3]: #build-l3 [build l4]: #build-l4 +[confidential computing]: https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/Common-Terminology-for-Confidential-Computing.pdf [future versions]: future-directions.md [hosted]: requirements.md#isolation-strength [previous version]: ../v0.1/levels.md [provenance]: terminology.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 [verification]: verifying-artifacts.md +[verification summary]: verification_summary.md From 0db3244b0c52e78fe91f3595f0fa89731a61c974 Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Tue, 7 May 2024 17:35:17 -0700 Subject: [PATCH 3/9] Add build environment model terminology Signed-off-by: Marcela Melara --- docs/spec/v1.1/terminology.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/spec/v1.1/terminology.md b/docs/spec/v1.1/terminology.md index 3047e0774..a1a25e61a 100644 --- a/docs/spec/v1.1/terminology.md +++ b/docs/spec/v1.1/terminology.md @@ -125,6 +125,38 @@ of build types](/provenance/v1#index-of-build-types). +### 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 provisions resources on the compute platform + and a build image launch a new build environment. For SLSA Build L4, the + build platform validates the *measurement* of the *boot process*. +3. When a new *build request* arrives at the hosted build platform, the + platform assigns the request to a pre-provisioned build environment. + For SLSA Build L4, the tenant may validate the measurement of the build + environment. +4. Finally, the build 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. +| Build executor | The platform-provided program dedicated to executing the tenant’s build definition, i.e., running the build, within the build image. +| Build request | The process of assigning a build to a pre-provisioned build environment on a hosted build process. +| 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 packages From 7f55357449fb20be1ea6bc43efb118469fbb432e Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Mon, 13 May 2024 10:19:23 -0700 Subject: [PATCH 4/9] Update docs/spec/v1.1/levels.md Co-authored-by: Dionna Amalie Glaze Signed-off-by: Marcela Melara --- docs/spec/v1.1/levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 02efa3b51..69e8f7356 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -244,7 +244,7 @@ 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 attestesting to the state of the +that supports hardware capabilities for attesting to the state of the compute environment executing builds.
Intended for
From f89d997fc462c1a820aa1712f68deea1dc5aa5fd Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Mon, 20 May 2024 16:27:38 -0700 Subject: [PATCH 5/9] Simplify the build platform requirements per review comments Signed-off-by: Marcela Melara --- docs/spec/v1.1/levels.md | 49 ++++++++-------------------------------- 1 file changed, 9 insertions(+), 40 deletions(-) diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 69e8f7356..2962afae8 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -26,7 +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 before the build +| [Build L4] | Attested build environment | Tampering during the build via the build environment @@ -265,45 +265,14 @@ All of [Build L3], plus: produce a [verification summary] about the check. - Build platform: - - Each build image (i.e., VM or container) made available to software - producers MUST be built on a SLSA Build L3+ platform. The generated - SLSA Provenance MUST be distributed to allow for independent - verification. - - Distribution of SLSA Provenance for pre-installed software within the - build image MAY be best-effort. - - The boot process of each build environment MUST be measured and - attested using a [TCG-compliant measured boot] mechanism. The - attestation MUST be authenticated and distributed for independent - verification. - - The initial state of the build environment's disk image MUST be - integrity measured and attested. The attestation MUST be - authenticated and distributed for independent verification. - - Read-write block devices or file system paths MUST be encrypted - with a key that is only accessible within the build image. - - Before launching a new environment based on a build image (i.e., VM - or container instance), its SLSA Provenance MUST be verified. - - Before making a build environment available for a build request: - - The boot process and state of disk image MUST be verified, and - cryptographically bound to the build image's valid SLSA provenance - to establish a verifiable integrity chain between a build image and - a build environment. - - A unique immutable build environment identifier (e.g., - cryptographic keypair) MUST be generated and cryptographically bound - to the build environment's integrity chain. - - These bindings MUST be authenticated and distributed for - independent verification. - - Before executing a tenant's build request (e.g., GHA build job): - - The build environment's integrity chain and uniqueness of its - immutable identifier MUST be verified. - - A unique immutable build request identifier (e.g., GHA build job - ID) MUST be generated and cryptographically bound to a valid build - environment integrity chain. - - All build platform generated attestations and cryptographic bindings - MUST be backed by a hardware root of trust (e.g., [TPM] or [trusted - execution environment]). Note: Virtual hardware (e.g., vTPM) MAY be - used to meet this requirement. - - Runtime changes to the build environment's disk image SHOULD be - observable at runtime by the executing build request. + - 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. + - 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 + the tenant.
Benefits
From d53f3d9a7aca9b41c22b435688c46836ee129f47 Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Tue, 21 May 2024 12:25:00 -0700 Subject: [PATCH 6/9] Add skeleton requirements to core spec Signed-off-by: Marcela Melara --- docs/spec/v1.1/requirements.md | 113 ++++++++++++++++++++++++++++----- 1 file changed, 96 insertions(+), 17 deletions(-) diff --git a/docs/spec/v1.1/requirements.md b/docs/spec/v1.1/requirements.md index 63f0e6b2b..9faf6218e 100644 --- a/docs/spec/v1.1/requirements.md +++ b/docs/spec/v1.1/requirements.md @@ -32,35 +32,42 @@ build level, implementing any controls as specified by the chosen platform. Implementer Requirement Degree - L1L2L3 + L1L2L3L4 Producer Choose an appropriate build platform - ✓✓✓ + ✓✓✓✓ Follow a consistent build process - ✓✓✓ + ✓✓✓✓ Distribute provenance - ✓✓✓ + ✓✓✓✓ - Build platform + Build platform Provenance generation Exists - ✓✓✓ + ✓✓✓✓ Authentic - ✓✓ + ✓✓✓ Unforgeable - ✓ + ✓✓ Isolation strength Hosted - ✓✓ + ✓✓ Isolated - ✓ + ✓ + + Build environment integrity + Measured + ✓ + + Hardware Attested + ✓ ### Security Best Practices @@ -153,7 +160,7 @@ minimum requirements on its: the build process? -
RequirementDescriptionL1L2L3 +
RequirementDescriptionL1L2L3L4
Provenance Exists @@ -182,7 +189,7 @@ Provenance. [SLSA Provenance]: provenance.md [associated suite]: ../../attestation-model#recommended-suite -✓✓✓ +✓✓✓✓
Provenance is Authentic *Authenticity:* Consumers MUST be able to validate the authenticity of the @@ -233,7 +240,7 @@ build platform (i.e. outside the trust boundary), except as noted below. the provenance. - Completeness of resolved dependencies is best effort. - ✓✓ + ✓✓✓
Provenance is Unforgeable *Accuracy:* Provenance MUST be strongly resistant to forgery by tenants. @@ -258,7 +265,7 @@ 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). - ✓ + ✓✓
### Isolation strength @@ -275,7 +282,7 @@ information on assessing a build platform's isolation strength, see [Verifying build platforms](verifying-systems.md). -
RequirementDescriptionL1L2L3 +
RequirementDescriptionL1L2L3L4
Hosted @@ -286,7 +293,7 @@ infrastructure, not on an individual's workstation. Examples: GitHub Actions, Google Cloud Build, Travis CI. - ✓✓ + ✓✓✓
Isolated @@ -330,7 +337,79 @@ 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). - ✓ + ✓✓ +
+ +### Build Environment Integrity + +[Build environment integrity]: #build-environment-integrity + +TODO + + + + +
RequirementDescriptionL1L2L3L4 + +
Measured + + +TODO + + ✓ +
Hardware Attested + + +The build platform ensured that the build steps ran in an isolated environment, +free of unintended external influence. In other words, any external influence on +the build was specifically requested by the build itself. This MUST hold true +even between builds within the same tenant project. + +The build platform MUST guarantee the following: + +**FIXME** + +- Each build image (i.e., VM or container) made available to software + producers MUST be built on a SLSA Build L3+ platform. The generated + SLSA Provenance MUST be distributed to allow for independent + verification. +- Distribution of SLSA Provenance for pre-installed software within the + build image MAY be best-effort. +- The boot process of each build environment MUST be measured and + attested using a [TCG-compliant measured boot] mechanism. The + attestation MUST be authenticated and distributed for independent + verification. +- The initial state of the build environment's disk image MUST be + integrity measured and attested. The attestation MUST be + authenticated and distributed for independent verification. +- Read-write block devices or file system paths MUST be encrypted + with a key that is only accessible within the build image. +- Before launching a new environment based on a build image (i.e., VM + or container instance), its SLSA Provenance MUST be verified. +- Before making a build environment available for a build request: + - The boot process and state of disk image MUST be verified, and + cryptographically bound to the build image's valid SLSA provenance + to establish a verifiable integrity chain between a build image and + a build environment. + - A unique immutable build environment identifier (e.g., + cryptographic keypair) MUST be generated and cryptographically bound + to the build environment's integrity chain. + - These bindings MUST be authenticated and distributed for + independent verification. +- Before executing a tenant's build request (e.g., GHA build job): + - The build environment's integrity chain and uniqueness of its + immutable identifier MUST be verified. + - A unique immutable build request identifier (e.g., GHA build job + ID) MUST be generated and cryptographically bound to a valid build + environment integrity chain. +- All build platform generated attestations and cryptographic bindings + MUST be backed by a hardware root of trust (e.g., [TPM] or [trusted + execution environment]). Note: Virtual hardware (e.g., vTPM) MAY be + used to meet this requirement. +- Runtime changes to the build environment's disk image SHOULD be + observable at runtime by the executing build request. + + ✓
[external parameters]: provenance.md#externalParameters From 9515e7c0976570ada3456adceb91bdc3d2d4b48b Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Tue, 21 May 2024 12:27:02 -0700 Subject: [PATCH 7/9] Add a few missing checkmarks in existing levels Signed-off-by: Marcela Melara --- docs/spec/v1.1/requirements.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/spec/v1.1/requirements.md b/docs/spec/v1.1/requirements.md index 9faf6218e..49c96d77e 100644 --- a/docs/spec/v1.1/requirements.md +++ b/docs/spec/v1.1/requirements.md @@ -57,10 +57,10 @@ build level, implementing any controls as specified by the chosen platform. Isolation strength Hosted - ✓✓ + ✓✓✓ Isolated - ✓ + ✓✓ Build environment integrity Measured From 98b6c43daf75fa2a53242f91e7a0cf8d78e9c4de Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Wed, 22 May 2024 18:27:55 -0700 Subject: [PATCH 8/9] Finish first draft of core requirements Signed-off-by: Marcela Melara --- docs/spec/v1.1/levels.md | 26 ++----- docs/spec/v1.1/requirements.md | 138 ++++++++++++++++----------------- docs/spec/v1.1/terminology.md | 17 ++-- 3 files changed, 83 insertions(+), 98 deletions(-) diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md index 2962afae8..c075f00ff 100644 --- a/docs/spec/v1.1/levels.md +++ b/docs/spec/v1.1/levels.md @@ -261,8 +261,8 @@ All of [Build L3], plus: - Software producer: - MUST run builds on a hosted build platform that meets Build L4 requirements. - - SHOULD verify the build platform's attestations prior to a build and - produce a [verification summary] about the check. + - 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 @@ -280,18 +280,11 @@ 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 information about the build image’s provenance - beyond self-attestation by the build platform operator. -- Provides cryptographic, hardware-rooted evidence about: - - The initial state of the compute environment executing a build, such - as its boot settings (e.g., measured boot enabled), the bootloader and - kernel image. - - The initial state of the environment's disk image and its - configuration. - - The build environment that executed a particular run of a build. -- The use of [confidential computing] to meet these - requirements provides builds with additional data and code - confidentiality and tamper-evidence properties during build execution. +- Provides machine-checkable, cryptographic, hardware-rooted evidence + 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. @@ -303,13 +296,10 @@ All of [Build L3], plus: [build l2]: #build-l2 [build l3]: #build-l3 [build l4]: #build-l4 -[confidential computing]: https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/Common-Terminology-for-Confidential-Computing.pdf +[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 -[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 [verification]: verifying-artifacts.md [verification summary]: verification_summary.md diff --git a/docs/spec/v1.1/requirements.md b/docs/spec/v1.1/requirements.md index 49c96d77e..ddf6286d9 100644 --- a/docs/spec/v1.1/requirements.md +++ b/docs/spec/v1.1/requirements.md @@ -44,7 +44,7 @@ build level, implementing any controls as specified by the chosen platform. Distribute provenance ✓✓✓✓ - Build platform + Build platform Provenance generation Exists ✓✓✓✓ @@ -55,18 +55,14 @@ build level, implementing any controls as specified by the chosen platform. Unforgeable ✓✓ - Isolation strength + Isolation strength Hosted ✓✓✓ Isolated ✓✓ - Build environment integrity - Measured - ✓ - - Hardware Attested + Hardware-Attested ✓ @@ -268,6 +264,8 @@ Note: This requirement was called "non-falsifiable" in the initial ✓✓ +TODO: Add completeness of resolved dependencies + ### Isolation strength [Isolation strength]: #isolation-strength @@ -277,9 +275,9 @@ 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). +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).
RequirementDescriptionL1L2L3L4 @@ -338,80 +336,76 @@ substantial changes to both the build platform and each individual build, and is considered in the [future directions](future-directions.md). ✓✓ -
- -### Build Environment Integrity - -[Build environment integrity]: #build-environment-integrity - -TODO - - - - -
RequirementDescriptionL1L2L3L4 - -
Measured - - -TODO - - ✓
Hardware Attested +Hardware-Attested -The build platform ensured that the build steps ran in an isolated environment, -free of unintended external influence. In other words, any external influence on -the build was specifically requested by the build itself. This MUST hold true -even between builds within the same tenant project. +The build platform generated an authenticated attestation to the integrity +of the entire initial state of the build environment (i.e., VM/container +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. The build platform MUST guarantee the following: -**FIXME** - -- Each build image (i.e., VM or container) made available to software - producers MUST be built on a SLSA Build L3+ platform. The generated - SLSA Provenance MUST be distributed to allow for independent - verification. -- Distribution of SLSA Provenance for pre-installed software within the - build image MAY be best-effort. -- The boot process of each build environment MUST be measured and - attested using a [TCG-compliant measured boot] mechanism. The - attestation MUST be authenticated and distributed for independent +- When creating a new build environment: + - 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 + MUST be integrity measured and attested. The boot and disk + attestations MUST be distributed to allow for independent verification. -- The initial state of the build environment's disk image MUST be - integrity measured and attested. The attestation MUST be - authenticated and distributed for independent verification. -- Read-write block devices or file system paths MUST be encrypted - with a key that is only accessible within the build image. -- Before launching a new environment based on a build image (i.e., VM - or container instance), its SLSA Provenance MUST be verified. -- Before making a build environment available for a build request: - - The boot process and state of disk image MUST be verified, and - cryptographically bound to the build image's valid SLSA provenance - to establish a verifiable integrity chain between a build image and - a build environment. - - A unique immutable build environment identifier (e.g., +- When deploying a new build environment: + - 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's integrity chain. - - These bindings MUST be authenticated and distributed for - independent verification. -- Before executing a tenant's build request (e.g., GHA build job): - - The build environment's integrity chain and uniqueness of its - immutable identifier MUST be verified. - - A unique immutable build request identifier (e.g., GHA build job - ID) MUST be generated and cryptographically bound to a valid build - environment integrity chain. -- All build platform generated attestations and cryptographic bindings - MUST be backed by a hardware root of trust (e.g., [TPM] or [trusted - execution environment]). Note: Virtual hardware (e.g., vTPM) MAY be - used to meet this requirement. -- Runtime changes to the build environment's disk image SHOULD be - observable at runtime by the executing build request. + to the build environment via attestation. This _deploy-time + 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 + 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 + by a hardware root of trust (e.g., [TPM] or [trusted execution + 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. ✓
+[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 diff --git a/docs/spec/v1.1/terminology.md b/docs/spec/v1.1/terminology.md index a1a25e61a..26174d5b5 100644 --- a/docs/spec/v1.1/terminology.md +++ b/docs/spec/v1.1/terminology.md @@ -137,14 +137,15 @@ 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 provisions resources on the compute platform - and a build image launch a new build environment. For SLSA Build L4, the - build platform validates the *measurement* of the *boot process*. -3. When a new *build request* arrives at the hosted build platform, the - platform assigns the request to a pre-provisioned build environment. - For SLSA Build L4, the tenant may validate the measurement of the build - environment. -4. Finally, the build environment executes the tenant's build steps. +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 | --- | --- From a531f5057febb5fdf8c290f27aa215a5599bba35 Mon Sep 17 00:00:00 2001 From: Marcela Melara Date: Wed, 22 May 2024 18:30:18 -0700 Subject: [PATCH 9/9] Make linter happy Signed-off-by: Marcela Melara --- docs/spec/v1.1/requirements.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/spec/v1.1/requirements.md b/docs/spec/v1.1/requirements.md index ddf6286d9..9736a57ad 100644 --- a/docs/spec/v1.1/requirements.md +++ b/docs/spec/v1.1/requirements.md @@ -368,8 +368,8 @@ The build platform MUST guarantee the following: 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 - attestation_ MUST be generated only after build image, boot process + to the build environment via attestation. This *deploy-time + 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): @@ -378,7 +378,7 @@ The build platform MUST guarantee the following: 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_ + 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