What permissions do the GitHub Actions need? about clusterfuzzlite HOT 15 CLOSED

@jonathanmetzman thanks for sharing

Hi @varunsh-coder!
All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

I'm not really sure which permissions we are using. We need to read repos and artifacts. Can you tell me how I can figure this out?

@jonathanmetzman We usually just do a code review of the Action, and look for wherever the GitHub token is being used. Then map the GitHub API calls being made to token permissions as per this page. In this case the Action is pointing to a docker image, but I am not sure where the codebase for that image is. Read repos and artifacts would translate to contents: read and actions: read. Can you please point me to the repo? I can do a quick review and confirm my understanding by posting results here...

It's here: https://github.com/google/oss-fuzz/tree/master/infra/cifuzz

@jonathanmetzman Thanks for sharing the info.

By my analysis,

• if you look here, only specific endpoint is accessed with github_token.
• As per here, this endpoint requires only actions: read, permission.

@h0x0er I think it also needs contents: read https://github.com/google/oss-fuzz/blob/a458e3c8edc4191488bca4563bc1bcf92043226b/infra/cifuzz/continuous_integration.py#L122
I tried on a private repo, and without this, it could not clone the repo.

@jonathanmetzman thanks for the info! closing this issue. We do not have a good process to find out changes to token permissions in different Actions as of now. If new permissions get used, please create an issue/ PR at step-security/secure-workflows. It might be good to document the permissions at https://google.github.io/clusterfuzzlite/running-clusterfuzzlite/github-actions/#private-repos

from clusterfuzzlite.

Hi @varunsh-coder!

All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

from clusterfuzzlite.

Hi @varunsh-coder!

All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

from clusterfuzzlite.

I don't think CFLite is supposed to be run along with jobs requiring write permissions. If it's included in a pipeline of some kind it should be a separate job with read permissions.

I think scorecard and all the tools surrounding it should be more interested in https://google.github.io/clusterfuzzlite/running-clusterfuzzlite/github-actions/#extra-configuration but it seems that's not what this issue is about.

from clusterfuzzlite.

FWIW scorecard already thinks that both CIFuzz and CFLite are insecure

  "score": 6.0,
  "checks": [
    {
      "details": [
        "Warn: third-party action not pinned by hash: .github/workflows/cflite_pr.yml:28",
        "Warn: third-party action not pinned by hash: .github/workflows/cflite_pr.yml:34",
        "Warn: third-party action not pinned by hash: .github/workflows/cifuzz.yml:37",
        "Warn: third-party action not pinned by hash: .github/workflows/cifuzz.yml:44",
        "Info: GitHub-owned actions are pinned",
        "Warn: docker image not pinned by hash: .clusterfuzzlite/Dockerfile:1",
        "Info: no insecure (not pinned by hash) dependency downloads found in Dockerfiles",
        "Info: no insecure (not pinned by hash) dependency downloads found in shell scripts",
        "Info: no insecure (not pinned by hash) dependency downloads found in GitHub workflows"

so projects concerned about their scores are unlikely to use them until it's fixed.

from clusterfuzzlite.

I forgot to cc @laurentsimon :-)

From #86 (comment)

I think scorecard and all the tools surrounding it should be more interested in https://google.github.io/clusterfuzzlite/running-clusterfuzzlite/github-actions/#extra-configuration but it seems that's not what this issue is about.

from clusterfuzzlite.

Just to clarify I'm not saying that that token is insecure. It's just that it's an example of an action where a token that can be used to overwrite another repository is hidden in plain sight and neither scorecard nor the knowledge database can handle that.

from clusterfuzzlite.

Hi @varunsh-coder!
All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

I'm not really sure which permissions we are using. We need to read repos and artifacts. Can you tell me how I can figure this out?

from clusterfuzzlite.

Just to clarify I'm not saying that that token is insecure. It's just that it's an example of an action where a token that can be used to overwrite another repository is hidden in plain sight and neither scorecard nor the knowledge database can handle that.

this sounds interesting, but not sure I understand. Can you explain this in more dumbed down terms? How can this token be used to overwrite another repo?

from clusterfuzzlite.

@jonathanmetzman sorry. What I was trying to say is that if a storage repository is used CFLite needs a token to be able to write to that repository to update it so even though the permissions in the action itself are read-only and protect the original repository the PAT token still has write access to the storage repository. In this particular case it's harmless but that pattern is potentially dangerous and should probably be detected.

from clusterfuzzlite.

Hi @varunsh-coder!
All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

I'm not really sure which permissions we are using. We need to read repos and artifacts. Can you tell me how I can figure this out?

@jonathanmetzman We usually just do a code review of the Action, and look for wherever the GitHub token is being used. Then map the GitHub API calls being made to token permissions as per this page. In this case the Action is pointing to a docker image, but I am not sure where the codebase for that image is. Read repos and artifacts would translate to contents: read and actions: read. Can you please point me to the repo? I can do a quick review and confirm my understanding by posting results here...

from clusterfuzzlite.

Read repos and artifacts would translate to contents: read and actions: read

FWIW the action writes artifacts as well but GitHub somehow allows that even with read-only tokens. I wonder what those API calls would translate to?

from clusterfuzzlite.

As far as I know the actions are at https://github.com/google/oss-fuzz/tree/master/infra/cifuzz/external-actions. They refer to https://github.com/google/oss-fuzz/blob/master/infra/build_fuzzers.Dockerfile and https://github.com/google/oss-fuzz/blob/master/infra/run_fuzzers.Dockerfile. It would be interesting to take a look at the results.

We usually just do a code review of the Action, and look for wherever the GitHub token is being used.

Just out of curiosity, I wonder if actions are reviewed once (when they are integrated into the database) or they are reviewed every time they get updated? Thanks!

from clusterfuzzlite.

Hi @varunsh-coder!
All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

I'm not really sure which permissions we are using. We need to read repos and artifacts. Can you tell me how I can figure this out?

@jonathanmetzman We usually just do a code review of the Action, and look for wherever the GitHub token is being used. Then map the GitHub API calls being made to token permissions as per this page. In this case the Action is pointing to a docker image, but I am not sure where the codebase for that image is. Read repos and artifacts would translate to contents: read and actions: read. Can you please point me to the repo? I can do a quick review and confirm my understanding by posting results here...

It's here: https://github.com/google/oss-fuzz/tree/master/infra/cifuzz

from clusterfuzzlite.

@jonathanmetzman thanks for sharing

Hi @varunsh-coder!
All of our CFLite workflows set a top level permissions: read-all for the default GITHUB_TOKEN. No 'write' permissions are needed.

Thanks @oliverchang! Unfortunately, we need to know the specific read permissions. What happens is that if someone uses these actions in a job, and that job also needs some write permissions (because of a different action), then read-all does not work along with some write permissions. Request you to please let me know the specific read permissions. In fact, we also need the reason for the permissions in the KB.

I'm not really sure which permissions we are using. We need to read repos and artifacts. Can you tell me how I can figure this out?

@jonathanmetzman We usually just do a code review of the Action, and look for wherever the GitHub token is being used. Then map the GitHub API calls being made to token permissions as per this page. In this case the Action is pointing to a docker image, but I am not sure where the codebase for that image is. Read repos and artifacts would translate to contents: read and actions: read. Can you please point me to the repo? I can do a quick review and confirm my understanding by posting results here...

It's here: https://github.com/google/oss-fuzz/tree/master/infra/cifuzz

@jonathanmetzman Thanks for sharing the info.

By my analysis,

• if you look here, only specific endpoint is accessed with github_token.
• As per here, this endpoint requires only actions: read, permission.

from clusterfuzzlite.