GitHub Actions: Add permission:{} to reduce GITHUB_TOKEN leak attack surface

[Ayesh]

Trac ticket: https://core.trac.wordpress.org/ticket/59805

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[desrosj]

Thanks for this, @Ayesh!

I did a little bit of digging, and this is explicitly noted in the Reusing Workflows documentation:

• If jobs.<job_id>.permissions is not specified in the calling job, the called workflow will have the default permissions for the GITHUB_TOKEN.
• The GITHUB_TOKEN permissions passed from the caller workflow can be only downgraded (not elevated) by the called workflow.

We are currently passing permissions to the callable workflows with contents: read in the calling workflows with a few exceptions in the upgrade-testing.yml file. It seems the first testing job only has permissions defined. We should add that.

I'm trying to think through scenarios where not having permissions in the callable workflow would be problematic if we're always explicitly passing permissions. Additionally, since the workflow is hard coded to use the version found within trunk (which can only be committed to through SVN), I'm not sure if we need to. I guess the scenario would need to be:

• Create a PR changing the target branch for the called workflow.
• Remove permissions within that branch in the calling workflow.
• Change the called workflow to misuse/escalate $GITHUB_TOKEN.
  However, I don't think that this would have any affect. The maximum access for pull requests from public forked repositories is read for all scopes. The attacker would need to use pull_request_target, and that does not work unless the workflow exists within the base branch with pull_request_target as well.