ci: add GitHub token permissions for workflow

[varunsh-coder]

This PR adds minimum token permissions for the GITHUB_TOKEN.

GitHub recommends defining minimum GITHUB_TOKEN permissions for securing GitHub Actions workflows

• https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
• https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
• The Open Source Security Foundation (OpenSSF) Scorecards treats not setting token permissions as a high-risk issue

Signed-off-by: Varun Sharma varunsh@stepsecurity.io

Before this change

GITHUB_TOKEN has write permissions for multiple scopes which are not needed.
e.g. https://github.com/oracle/truffleruby/runs/7521413259?check_suite_focus=true#step:1:16

After this change

GITHUB_TOKEN will have minimum permissions needed

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: @varunsh-coder
• varunsh@stepsecurity.io (@varunsh-coder)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When singing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

[eregon]

I'm not sure what this gains.
As the blog post makes it clear, it's already only read access from forks.
And anyone with push access to this repository is trusted.
But even then, it seems adding this line wouldn't help, since anyone with push rights on this repo could then also just remove it.
So, am I missing something or this does not actually improve anything security-wise?

[varunsh-coder]

I'm not sure what this gains.
As the blog post makes it clear, it's already only read access from forks.
And anyone with push access to this repository is trusted.
But even then, it seems adding this line wouldn't help, since anyone with push rights on this repo could then also just remove it.
So, am I missing something or this does not actually improve anything security-wise?

Hi @eregon, that is a good question. The threat this change is trying to mitigate is not from the maintainers who are trusted and have push access.

The threat is if one of the components/ GitHub Actions used in the workflow are vulnerable or have been compromised, it can be used to exfiltrate the GITHUB_TOKEN. Here are couple of past examples:

• A security researcher used a vulnerable GitHub Action used by VS Code to exfiltrate GITHUB_TOKEN and update a release branch
• Code used in the Codecov Action was compromised by attackers to exfiltrate secrets.

HTH. Please let me know if you have any follow up questions.

[eregon]

The threat is if one of the components/ GitHub Actions used in the workflow are vulnerable or have been compromised, it can be used to exfiltrate the GITHUB_TOKEN.

I'd like to understand the threat more in detail, to see how much this helps.

The only actions used here are:

• actions/checkout@v2
• ruby/setup-ruby@v1
• actions/cache@v2
• actions/upload-artifact@v2
• actions/download-artifact@v2

The GITHUB_TOKEN is not given explicitly to any of those actions.
AFAIK, actions do not get access to the token, except for some actions maintained by GitHub, like actions/checkout.

If one of the actions/* is compromised (i.e., its code is changed maliciously), then it already grants RCE on GitHub-hosted runners but I guess that's nothing special since one has the same by writing their own workflow.

It might also grant access to the GITHUB_TOKEN, and that could be used to write to basically every single GitHub repository using actions/checkout. I guess this change would limit it to only read access, but if something like this happen, GitHub is basically responsible for that and all of GitHub is insecure, no?

Unfortunately both articles are very unclear about the actual issue.
Maybe the first one is about a workflow passing the token explicitly to some other action, which apparently can be triggered by any user, and that got exploited? That doesn't apply here, the token is not passed anywhere explicitly.

Something a bit worrying is https://github.com/actions/checkout/blob/2541b1294d2704b0964813337f33b291d3f8596b/action.yml#L14-L16 + https://github.com/actions/checkout/blob/2541b1294d2704b0964813337f33b291d3f8596b/action.yml#L48-L50:

  Personal access token (PAT) used to fetch the repository. The PAT is configured
  with the local git config, which enables your scripts to run authenticated git
  commands. The post-job step removes the PAT.

That sounds like it saves the token in .git/config, and then any process/action part of the workflow could read it and leak it potentially.
If that is the case, that sounds like the default to do that is very questionable for actions/checkout (instead it could clean the token as soon as the action is done, or maybe not use a token at all by default).
Update: indeed, it saves it to .git/config which can be read easily.

[eregon]

Alright, given how easy it is to get the token from .git/config, I think this is useful.
OTOH, I feel it's very irresponsible of actions/checkout to make the token so easy to access for anything running in the workflow. That can be mitigated by persist-credentials: false but that's rather inconvenient and seems like it should clearly be the default (actions/checkout#485).

[varunsh-coder]

Good point on the .git/config file and the persist-credentials: false default. I will read up more about it.

To answer your initial question, any GitHub Action can get access to the GITHUB_TOKEN by updating the Action's action.yml file. Here are some examples of Actions that get the GITHUB_TOKEN.

https://github.com/peter-evans/create-pull-request/blob/10db75894f6d53fc01c3bb0995e95bd03e583a62/action.yml#L6
https://github.com/dawidd6/action-download-artifact/blob/882d744ccc51cb8b3dc88e9c075cd723ebb9215a/action.yml#L11

Moreover, once the Action's action.yml file is updated, the workflows that are using the Action do not need to be updated. The token will get passed to the Action without explicitly passing the token in the workflow.

So, if an attacker can compromise an Action, they can update the action.yml file and get the GITHUB_TOKEN...

[eregon]

To answer your initial question, any GitHub Action can get access to the GITHUB_TOKEN by updating the Action's action.yml file. Here are some examples of Actions that get the GITHUB_TOKEN.

https://github.com/peter-evans/create-pull-request/blob/10db75894f6d53fc01c3bb0995e95bd03e583a62/action.yml#L6 https://github.com/dawidd6/action-download-artifact/blob/882d744ccc51cb8b3dc88e9c075cd723ebb9215a/action.yml#L11

I remember trying that myself with @fniephaus and the result was this default: ${{ github.token }} actually resulted in an empty input in that action, i.e., it did not get the token. I'll try it again to make sure, maybe we did something wrong.

[eregon]

I changed the permissions in the repository settings, so now it's read-only: https://github.com/oracle/truffleruby/runs/7545551461?check_suite_focus=true
I think we should still merge this for clarity though.

[varunsh-coder]

w.r.t the OCA check which is failing, I did sign that one day back. may be it takes some time to propagate here...