[feature] Use CLI tools instead of third-party GitHub Actions in the generator

[behnazh-w]

For GitHub projects that enforce an allow-list for third-party GitHub Actions, like Macaron, it would be necessary to avoid calling the third-party GitHub Actions in the provenance generator and instead use CLI tools. These are the three GitHub Actions used by the generator and reported in this run, each of which might also be calling other GitHub Actions:

• google-github-actions/auth
• sigstore/cosign-installer
• softprops/action-gh-release

For example the action-gh-release Action can easily be replaced by gh , which is available by default on the Ubuntu runners.

Note that GitHub enforces the allow-list statically. So, even if a GitHub Action is called conditionally, it will result in a startup failure.

[ianlewis]

Hey @behnazh-w, can you point us to docs or info on the allow list you're using and how it's enforced?

[ianlewis]

I think this is related to the issue you had on #1711 right?

[ianlewis]

Note that GitHub enforces the allow-list statically. So, even if a GitHub Action is called conditionally, it will result in a startup failure.

Right. This seems similar to the permissions issues we have. We could solve this by providing separate workflows for functionality like we did with the "lowperms" delegator workflow for BYOB.

These are the three GitHub Actions used by the generator and reported in this run, each of which might also be calling other GitHub Actions:

• google-github-actions/auth
• sigstore/cosign-installer
• softprops/action-gh-release

I think sigstore/cosign-installer and softprops/action-gh-release could potentially be replaced relatively easily. We also have been leaning towards more modular workflows and not doing the release as part of the workflows (at least for newer workflows we've developed).

google-github-actions/auth would be pretty difficult to replicate though. We absolutely have to do the auth call inside the workflow so we can't extract that functionality, so I think the only solution would be to create a separate workflow that doesn't make the call.

[behnazh-w]

Hey @behnazh-w, can you point us to docs or info on the allow list you're using and how it's enforced?

Our organization enforces an allow list for GitHub Actions based on this feature in GitHub. Such an allow list is applied at an organization level and is statically enforced as mentioned earlier.

[behnazh-w]

I think this is related to the issue you had on #1711 right?

Yes it is related. However now we have approval for slsa-framework/slsa-github-generator reusable workflow but not its dependencies. Such policies are applied to reduce the attack surface given the supply chain issues in third-party GitHub Actions.

[ianlewis]

Thanks that's helpful extra context!

[mcaulifn]

There is a related issue of only utilizing self-hosted runners. Some enterprises/orgs do not allow the use of GH hosted runners. These workflows would get a start-up error as they utilize ubuntu-latest.

It would be better if this could be re-written as a TS action that performed the necessary steps. That would remove the need for specific labels and also allow this repo to be replicated internally for those that do not allow access to public actions.

[ianlewis]

There is a related issue of only utilizing self-hosted runners. Some enterprises/orgs do not allow the use of GH hosted runners. These workflows would get a start-up error as they utilize ubuntu-latest.

Currently the builders rely on properties of the GH hosted runners that self-hosted runners don't have so we can't really provide the same security model using self-hosted runners currently. We would like to support self-hosted runners at some point but I'm not sure that it's possible currently.

It would be better if this could be re-written as a TS action that performed the necessary steps. That would remove the need for specific labels and also allow this repo to be replicated internally for those that do not allow access to public actions.

Reusable workflows were specifically chosen for their properties of running in separate job VM from a user's job, and that the OIDC tokens provided by GitHub include the currently executing workflow's path. This allows us to verify that the provenance was generated and signed isolated from the user's job.

A TS action executes much like a regular script so it would simply run in the same VM along with the user's build, potentially providing it access to the provenance generation process and key material used for signing. It would also get the same OIDC tokens allowing user builds to sign provenance in the same way as we would. This wouldn't address the threats laid out in our threat model so haven't provided actions for generating provenance thus far.

[mcaulifn]

Reusable workflows were specifically chosen for their properties of running in separate job VM from a user's job, and that the OIDC tokens provided by GitHub include the currently executing workflow's path. This allows us to verify that the provenance was generated and signed isolated from the user's job.

Makes perfect sense. Thanks for the info!

What is needed to allow self-hosted runners? I found slsa-framework/slsa#966

Any idea if there are there tools that support self-hosted runners? I would image that GHES runners have this same issue.

[ianlewis]

Makes perfect sense. Thanks for the info!

You're very welcome! :)

What is needed to allow self-hosted runners? I found slsa-framework/slsa#966

Right. I think they are thinking of generic "self-hosted runners" in the sense that it could be anything that interacts with the CI's API not just the platform's official self-hosted runner.

In short, to achieve SLSA Build lvl 3+ the runner needs to provide a way to isolate or sandbox the users build so that it runs in an untrusted context (in practice, this is a specially crafted VM or something like a gVisor sandbox) and doesn't have access to the runner itself or the provenance generation or the key material used to sign the provenance.

Anyone who has access to the machine that the runner is running on could also compromise the build so users need to explicitly trust whoever that is in addition to the CI platform itself (e.g. GitHub) if they are different people. I believe this is why they are saying on slsa-framework/slsa#966 that the runner needs to have its own builder.id so that users can explicitly trust it when doing verification.

Any idea if there are there tools that support self-hosted runners? I would image that GHES runners have this same issue.

Right, any self-hosted runners would have this issue. I haven't looked much into self-hosted runners but my guess is there are very few that support anything like sandboxing user builds with security in mind.