github: scope/narrow permissions, prevent template injection via GHA, enable zizmor workflow #5076
+85
−17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This stops issuing overly broad permissions to the entire workflow and instead scopes them to the necessary steps in the job. Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
There's literally no need for permissions of any kind in this workflow, and furthermore this disables credential persistence for Git commands. Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
The dependabot workflow already specifies the exact permissions it needs within the workflow steps, so there's no need to enable any default permissions. Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
…aries workflow Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
In theory this could be exploited by a contributor who pushes a tag with a specifically crafted name in order to exfiltrate a `GITHUB_TOKEN` that has permissions on the jj repository. This token would be scoped narrowly ideally, but... Today, Martin does releases manually, so this workflow currently does not e.g. have the ability to upload a compromised package to crates.io. However in the future we'd like to have the release done automatically via workflow as well, which would make this potential injection vector catastrophic if the injection was possible in a step with a crates.io API token available. Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
This should help us catch GHA security flaws much earlier. Signed-off-by: Austin Seipp <[email protected]>
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
|
I haven't tested the release workflow in my thoughtpolice/jj repository yet, so this is currently in draft until I can make sure nothing broke due to a missed permission. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a series of changes to the workflow files suggested by the
zizmortool, an automated security scanner for GitHub Actions Workflows. At the very end, it also adds a new workflow which will automatically runzizmoron all changes going forward.Context: there was a recent compromise of a very popular pypi package named
ultralyticsthat occurred due to template injection through a pushed tag. GHA has also had a long string of security vulnerabilitiesAlmost all of the suggested changes were low-priority, related to:
read-allwhen we either didn't need it, or only needed it for extremely few steps), and$HOME/.gitstorage when running checkout — which could be exploited by steps that read and exfiltrated them.In our case, neither of these features were necessary, so removing them is easy. However...
It also found real template injection vulnerabilities in the
release.ymlworkflow, which in theory could be exploited by contributors who pushed tags (I am not sure if anyone except Martin is capable of pushing tags now, but it's easier to assume the answer is "yes").I don't believe these could be exploited in a meaningful way today by any (compromised) contributor because the only thing you could exfiltrate is a narrowly scoped
$GITHUB_TOKENcredential. However, I filed #2483 last year to automate the release workflow, which would necessarily expose a https://crates.io API token to the release workflow — which could have then been potentially exfiltrated via this vulnerability, resulting in absolute catastrophe.Checklist
If applicable:
CHANGELOG.md