From 24ee58c399b9ea8838b462d45a8771038febb638 Mon Sep 17 00:00:00 2001 From: Alex Date: Thu, 8 Dec 2022 19:40:24 +0200 Subject: [PATCH] ci: harden configuration This makes it so the permissions are locked down by default. The threat model here is something like, "what happens if an authorized party gains control of the non-PR CI configuration somehow." To be honest, I (BurntSushi) don't quite understand how that might happen without also the ability to set the permissions itself. But locking permissions down by default does seem like a good and sensible thing to do. Closes #932 --- .github/workflows/ci.yml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index ac2ace4..7c04a74 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -6,6 +6,27 @@ on: - master schedule: - cron: '00 01 * * *' + +# The section is needed to drop write-all permissions that are granted on +# `schedule` event. By specifying any permission explicitly all others are set +# to none. By using the principle of least privilege the damage a compromised +# workflow can do (because of an injection or compromised third party tool or +# action) is restricted. Currently the worklow doesn't need any additional +# permission except for pulling the code. Adding labels to issues, commenting +# on pull-requests, etc. may need additional permissions: +# +# Syntax for this section: +# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions +# +# Reference for how to assign permissions on a job-by-job basis: +# https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs +# +# Reference for available permissions that we can enable if needed: +# https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token +permissions: + # to fetch code (actions/checkout) + contents: read + jobs: test: name: test