SLSA v1.0: Add "Verifying Build Systems" #568

kpk47 · 2023-01-10T23:15:48Z

Addresses #508 .

Signed-off-by: kpk47 <[email protected]>

netlify · 2023-01-10T23:16:20Z

✅ Deploy Preview for slsa ready!

Name	Link
🔨 Latest commit	`f6af2be`
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/63c1dbfbe73cbd000ae17727
😎 Deploy Preview	https://deploy-preview-568--slsa.netlify.app/spec/v1.0
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

docs/spec/v1.0/output.md

Signed-off-by: kpk47 <[email protected]>

SecKatie

Overall I think this is great! There are only a few typos that need to be fixed and I think there are some areas that we can improve, especially when it comes to cryptographic secret security

docs/spec/v1.0/verifying_systems.md

SecKatie · 2023-01-12T17:16:14Z

docs/spec/v1.0/verifying_systems.md

+-   Creating executors
+    -   How does the control plane share data with executors? Example: mounting a shared file system partition
+    -   How does the control plane protect its integrity from executors? Example: not mount its own file system partitions on executors
+    -   How does the control plane prevent executors from accessing its cryptographic secrets? Examples: dedicated secret storage, not mounting its own file system partitions on executors


We may want to also mention hardware security modules here

docs/spec/v1.0/verifying_systems.md

MarkLodato

This looks great to me! I just have some minor suggestions

docs/spec/v1.0/verifying_systems.md

MarkLodato · 2023-01-12T18:02:34Z

docs/spec/v1.0/verifying_systems.md

+
+### Types of attackers
+
+We consider three attacker profiles differentiated by the attacker's capabilities and privileges.


Right now this section is a bit unclear on the meaning of terms like "the source repo", "their", and "the package". Maybe explain that there is a "target" repo/project? Then in low privilege, "their" can be used to describe the attacker creating a separate project unrelated to the target?

I tried to clarify this section by drawing a distinction between the "target build" and "controlled builds." It may be a bit clunky.

docs/spec/v1.0/verifying_systems.md

docs/spec/v1.0/index.md

Signed-off-by: kpk47 <[email protected]>

abacchi · 2023-01-13T14:30:08Z

docs/spec/v1.0/verifying_systems.md

+Note: Platform abuse (e.g. running non-build workloads) and attacks against builder availability are out of scope of this document.
+
+TODO: Align/cross-reference with SLSA Provenance Model.
+TODO: Redraw diagrams in the style used by the rest of the site.


@MarkLodato who has created the diagrams before?

We had a design firm (Projects by IF) draw them initially, and then I have since updated them. It's in Figma format, with the source at https://github.com/slsa-framework/slsa/tree/main/resources/editable-diagrams. You can create a free account. Figma has a bit of a learning curve, but it has a lot of features for power users, such as components.

Sadly there is no clean version control integration, so I just download the .fig file and check it in whenever I update the diagram, which is as light pain.

For this PR, I think any diagram is fine, then we can clean it up once we get close to publishing.

abacchi · 2023-01-13T14:32:15Z

docs/spec/v1.0/verifying_systems.md

+
+-   Examples
+    -   Anyone on the internet
+    -   Build servec insiders without administrative access


Should be "Build service"

abacchi · 2023-01-13T14:44:08Z

docs/spec/v1.0/verifying_systems.md

+    -   What is your process for responding to vulnerability disclosures? What about vulnerabilities in your dependencies?
+
+-   Creation and destruction
+    -   What environment is available in executors on creation? How were the elements of this environment chosen?


Are you able to append an example for what you'd expect an answer for "What environment is available"?

abacchi · 2023-01-13T14:51:30Z

Great work! Thinking about the user experience for someone wanting to fill out the assessment-
I could see a next step once this is finalized to create some sort of consolidated questionnaire with just the questions for folks to use. That way they wouldn't have to copy and paste different sections from the page.
Con to this: now we would need to keep this page and the pure questionnaire in sync any time there is a change.

docs/spec/v1.0/verifying_systems.md

MarkLodato · 2023-01-13T16:13:46Z

docs/spec/v1.0/verifying_systems.md

+Note: Platform abuse (e.g. running non-build workloads) and attacks against builder availability are out of scope of this document.
+
+TODO: Align/cross-reference with SLSA Provenance Model.
+TODO: Redraw diagrams in the style used by the rest of the site.


We had a design firm (Projects by IF) draw them initially, and then I have since updated them. It's in Figma format, with the source at https://github.com/slsa-framework/slsa/tree/main/resources/editable-diagrams. You can create a free account. Figma has a bit of a learning curve, but it has a lot of features for power users, such as components.

Sadly there is no clean version control integration, so I just download the .fig file and check it in whenever I update the diagram, which is as light pain.

For this PR, I think any diagram is fine, then we can clean it up once we get close to publishing.

MarkLodato · 2023-01-13T16:26:00Z

docs/spec/v1.0/verifying_systems.md


 ### Types of attackers

-We consider three attacker profiles differentiated by the attacker's capabilities and privileges.
+We consider three attacker profiles differentiated by the attacker's capabilities and privileges as related to the build they wish to subvert (the "target build").

 #### Low privilege


Have you thought about just calling these:

Everyone else (low privilege)

Project maintainer (medium privilege)

Build service admin (high privilege)

It seems like the rest of the doc does not use the low/medium/high profile terms anyway. Perhaps the alternates are easier to work in?

+1 to the alternatives

Considering private projects, I'd recommend to not use "Everyone else" rather something like "Developer" or "Contributor". I feel this could help apply for both public and private projects.

1 for alternatives though.

New wording is "Project contributors". (But it should be singular.)

But that seems overly narrow. An attacker could be someone who is not a contributor at all, no?

Fair point, we are talking about someone who is able to execute the capabilities:

Capabilities:

Create builds on the build service. These are the attacker's controlled builds.

Modify one or more controlled builds' external parameters.

Modify one or more controlled builds' environments and run arbitrary code inside those environments.

Read the target build's source repo.

Fork the target build's source repo.

Modify a fork of the target build's source repo and build from it.

I suppose they are an "Authenticated User" with those abilities. That would satisfy my concern about private / public projects.

docs/spec/v1.0/verifying_systems.md

MarkLodato · 2023-01-13T16:43:03Z

docs/spec/v1.0/verifying_systems.md


 TODO: Align/cross-reference with SLSA Provenance Model.
+TODO: Redraw diagrams in the style used by the rest of the site.

 ### Types of attackers


I like this list of attacker profiles, but the rest of the doc doesn't seem to use it. That seems like a missing piece, though I can't figure out exactly what's missing.

Maybe it's that the SLSA Build requirements are designed to protect against Low and Medium attackers, while protecting against High attackers is very complex and we need this "verifying systems" piece to convince consumers that they've done a good enough job?

MarkLodato · 2023-01-13T17:01:12Z

docs/spec/v1.0/verifying_systems.md


-#### Prompts for Assessing Parameters
+#### Prompts for Assessing External Parameters


also: What gives us confidence that there are no additional external parameters that are missing from the provenance, and that a future design change will not violate SLSA assumptions?

(I ask because the new GHA Variables is exactly this type of design change.)

docs/spec/v1.0/verifying_systems.md

joshuagl

Really nice work on this Kris. It looks great overall, I made a few minor comments on clarity and would like to see other's feedback addressed too.

Should we be adding a requirement that all build systems provide this information? My reading of the "Builder Evaluation" section suggests yes. If so, is that follow-on work?

joshuagl · 2023-01-13T17:17:52Z

docs/spec/v1.0/verifying_systems.md

+
+### Control Plane
+
+The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. The control plane generates and signs provenance for each SLSA Build L3+ build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane.


Suggested change

The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. The control plane generates and signs provenance for each SLSA Build L3+ build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane.

The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. At SLSA Build L3+ the control plane generates and signs provenance for each build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane.

I'm worried that folks could read the original phrasing as only L3+ builds are signed, but maybe I'm being overly pessimistic here. My suggestion may not actually help either. :-D

Done, though I used L2+ since that's when the service starts signing provenance.

joshuagl · 2023-01-13T17:22:54Z

docs/spec/v1.0/verifying_systems.md

+
+-   What sorts of caches are available to build executors?
+-   How are those caches populated?
+-   How do you defend against cache poisoning attacks?


Might re-phrase this as "How are cache contents validated before use?"

joshuagl · 2023-01-13T17:24:15Z

docs/spec/v1.0/verifying_systems.md

+
+## Builder Evaluation
+
+Organizations can either self-attest to their answers or seek an audit/certification from a third party. Questionnaires for self-attestation should be published on the internet. Questionnaires for third-party certification need not be published. All provenance generated by L3+ builders must contain a non-forgeable attestation of the builder's L3+ capabilities with a limited validity period. Any secret materials used to prove the non-forgeability of the attestation must belong to the attesting party.


We should probably expand on " All provenance generated by L3+ builders must contain a non-forgeable attestation of the builder's L3+ capabilities with a limited validity period." – what attestation? Why? What period?

This AI could be a TODO

I like the idea of this - maybe for SLSA 1.1 we could create a verified build system attestation spec :)

Added as a TODO. I'm hoping to squeeze it into 1.0 if possible.

joshuagl · 2023-01-13T17:26:22Z

docs/spec/v1.0/verifying_systems.md


 ### Types of attackers

-We consider three attacker profiles differentiated by the attacker's capabilities and privileges.
+We consider three attacker profiles differentiated by the attacker's capabilities and privileges as related to the build they wish to subvert (the "target build").

 #### Low privilege


+1 to the alternatives

abacchi · 2023-01-13T18:21:02Z

Should we be adding a requirement that all build systems provide this information?

It would make the maintainers' lives easier if the build system vendors were able to provide this to the best of their ability (maintainer may need to fill in some gaps)

Signed-off-by: kpk47 <[email protected]>

MarkLodato · 2023-01-13T20:35:06Z

docs/spec/v1.0/verifying_systems.md

@@ -0,0 +1,157 @@
+# Verifying Build Systems


nit: use hyphens to separate words, not underscores (e.g. use-cases.md, get-started.md, also that's Google's style guide). I suggest waiting until right before merging so that we don't lose comments.

docs/spec/v1.0/verifying_systems.md

Co-authored-by: Mark Lodato <[email protected]> Signed-off-by: kpk47 <[email protected]>

Signed-off-by: kpk47 <[email protected]>

kpk47 added 5 commits January 10, 2023 15:07

Add files via upload

a55d28b

Signed-off-by: kpk47 <[email protected]>

Add files via upload

b0a97c8

Signed-off-by: kpk47 <[email protected]>

Update verifying_systems.md

1b21bb6

Signed-off-by: kpk47 <[email protected]>

Update index.md

bfd1592

Signed-off-by: kpk47 <[email protected]>

Update verifying_systems.md

0a3ae1d

Signed-off-by: kpk47 <[email protected]>

kpk47 requested review from MarkLodato, mlieberman85 and joshuagl as code owners January 10, 2023 23:15

mlieberman85 reviewed Jan 10, 2023

View reviewed changes

docs/spec/v1.0/output.md Outdated Show resolved Hide resolved

kpk47 added 3 commits January 11, 2023 17:45

Merge branch 'main' of github.com:slsa-framework/slsa

5c59c75

Add workload identities to list of example mitigations

bc531ca

Signed-off-by: kpk47 <[email protected]>

lint

e404195

Signed-off-by: kpk47 <[email protected]>

SecKatie suggested changes Jan 12, 2023

View reviewed changes

MarkLodato requested changes Jan 12, 2023

View reviewed changes

kpk47 and others added 4 commits January 12, 2023 22:52

Addressing comments

d08a449

Signed-off-by: kpk47 <[email protected]>

Add files via upload

0f48461

Signed-off-by: kpk47 <[email protected]>

Merge branch 'main' of github.com:slsa-framework/slsa

1c3b95a

Add files via upload

444944a

Signed-off-by: kpk47 <[email protected]>

abacchi reviewed Jan 13, 2023

View reviewed changes

MarkLodato reviewed Jan 13, 2023

View reviewed changes

joshuagl reviewed Jan 13, 2023

View reviewed changes

kpk47 added 2 commits January 13, 2023 19:46

Addressing review comments

10a8d97

Signed-off-by: kpk47 <[email protected]>

Merge branch 'main' of github.com:kpk47/slsa

790b67a

MarkLodato approved these changes Jan 13, 2023

View reviewed changes

Update docs/spec/v1.0/verifying_systems.md

b3e67a7

Co-authored-by: Mark Lodato <[email protected]> Signed-off-by: kpk47 <[email protected]>

kpk47 and others added 4 commits January 13, 2023 22:10

Addressing code review comments

7aafd0d

Signed-off-by: kpk47 <[email protected]>

Merge branch 'main' of github.com:kpk47/slsa

e2e8c80

rename verifying_systems to verifying-systems

2866e69

Signed-off-by: kpk47 <[email protected]>

Update index.md

f6af2be

Signed-off-by: kpk47 <[email protected]>

abacchi approved these changes Jan 14, 2023

View reviewed changes

kpk47 merged commit 99ce983 into slsa-framework:main Jan 15, 2023

kpk47 mentioned this pull request Jan 19, 2023

Define "trusted control plane" #367

Closed


		### Types of attackers

		We consider three attacker profiles differentiated by the attacker's capabilities and privileges.


		#### Prompts for Assessing Parameters
		#### Prompts for Assessing External Parameters


		### Control Plane

		The control plane is the build system component that orchestrates each independent build execution. It is responsible for setting up each build and cleaning up afterwards. The control plane generates and signs provenance for each SLSA Build L3+ build performed on the system. The control plane is operated by one or more administrators, who have privileges to modify the control plane.


		## Builder Evaluation

		Organizations can either self-attest to their answers or seek an audit/certification from a third party. Questionnaires for self-attestation should be published on the internet. Questionnaires for third-party certification need not be published. All provenance generated by L3+ builders must contain a non-forgeable attestation of the builder's L3+ capabilities with a limited validity period. Any secret materials used to prove the non-forgeability of the attestation must belong to the attesting party.

SLSA v1.0: Add "Verifying Build Systems" #568

SLSA v1.0: Add "Verifying Build Systems" #568

Conversation

kpk47 commented Jan 10, 2023

netlify bot commented Jan 10, 2023 • edited Loading

✅ Deploy Preview for slsa ready!

SecKatie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MarkLodato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abacchi commented Jan 13, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshuagl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abacchi commented Jan 13, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

netlify bot commented Jan 10, 2023 •

edited

Loading