Skip to content
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

ci: add GitHub token permissions for workflow #2696

Merged
merged 1 commit into from
Jul 29, 2022

Conversation

varunsh-coder
Copy link
Contributor

This PR adds minimum token permissions for the GITHUB_TOKEN.

GitHub recommends defining minimum GITHUB_TOKEN permissions for securing GitHub Actions workflows

Signed-off-by: Varun Sharma [email protected]

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 oracle-contributor-agreement bot added the OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. label Jul 26, 2022
@oracle-contributor-agreement
Copy link

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:

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
Copy link
Member

eregon commented Jul 27, 2022

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
Copy link
Contributor Author

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:

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

@eregon
Copy link
Member

eregon commented Jul 27, 2022

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
Copy link
Member

eregon commented Jul 27, 2022

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
Copy link
Contributor Author

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
Copy link
Member

eregon commented Jul 27, 2022

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
Copy link
Member

eregon commented Jul 27, 2022

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
Copy link
Contributor Author

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...

@oracle-contributor-agreement oracle-contributor-agreement bot added OCA Verified All contributors have signed the Oracle Contributor Agreement. and removed OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. labels Jul 28, 2022
@eregon eregon added the in-ci The PR is being tested in CI. Do not push new commits. label Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in-ci The PR is being tested in CI. Do not push new commits. OCA Verified All contributors have signed the Oracle Contributor Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants