github: scope/narrow permissions, prevent template injection via GHA, enable zizmor workflow #5076
Conversation
|
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. |
thoughtpolice
force-pushed
the
aseipp/push-uvkmukvyzmzp
branch
from
17ab108 to
e6fd46f
Compare
thoughtpolice
force-pushed
the
aseipp/push-uvkmukvyzmzp
branch
from
e6fd46f to
f64bfbd
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
thoughtpolice
force-pushed
the
aseipp/push-uvkmukvyzmzp
branch
3 times, most recently
from
8a8930a to
46ccbb8
Compare
|
This might be interesting to @neongreen or relevant to #5117. |
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]>
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]>
Found by `zizmor`. Signed-off-by: Austin Seipp <[email protected]>
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 issues earlier. Signed-off-by: Austin Seipp <[email protected]>
thoughtpolice
force-pushed
the
aseipp/push-uvkmukvyzmzp
branch
from
46ccbb8 to
bdcba62
Compare
|
Lgtm (assuming it works). I will rebase my docs pipeline when this is merged |
|
Yeah, I think we can just get this in and fix any minor issues that come up in post. Thanks! |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
Getting this PR into |
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