-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Set permissions for GitHub actions #317
Conversation
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much. - Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) Signed-off-by: neilnaveen <[email protected]>
@jigpu Does it make sense to you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with this change, though I'd like to see similar changes made to the other two workflows. I suspect the checkpatch workflow can have this same permission set, while the tagged-release workflow likely needs contents: write
instead.
Jobs that use the GITHUB_TOKEN to perform sensitive actions on behalf of a real user may be granted a range of permissions. Instead of granting blanket permissions to read and write "all" APIs, we should really limit the permissions what any individual job can do. The only job that currently relies on a GITHUB_TOKEN is "tagged_release" which only needs read and write permissions for the "contents" scope. Link: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions Link: linuxwacom#317
Jobs that use the GITHUB_TOKEN to perform sensitive actions on behalf of a real user may be granted a range of permissions. Instead of granting blanket permissions to read and write "all" APIs, we should really limit the permissions what any individual workflow or job can do. This commit sets the default permissions for each workflow to "contents: read", which allows jobs to only read from the repository. The one job that requires additional permission is our "tagged_release" job which additional requires write access. Link: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions Link: linuxwacom#317
Jobs that use the GITHUB_TOKEN to perform sensitive actions on behalf of a real user may be granted a range of permissions. Instead of granting blanket permissions to read and write "all" APIs, we should really limit the permissions what any individual workflow or job can do. This commit sets the default permissions for each workflow to "contents: read", which allows jobs to only read from the repository. The one job that requires additional permission is our "tagged_release" job which additional requires write access. Link: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions Link: linuxwacom#317 Signed-off-by: Jason Gerecke <[email protected]>
Closing in favor of #400 which makes the requested modifications. |
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests
Signed-off-by: neilnaveen [email protected]