Great article! I also found this open source tool for sandboxing to be useful: https://github.com/bullfrogsec/bullfrog
Interesting project, I think I just found a way to crash the sandbox, just reported via an advisory.
How to harden GitHub Actions
41–50 of 74 posts
Re: How to harden GitHub Actions
#42This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
Where can I read about this? I see no reference in its repo: https://github.com/search?q=repo%3Atj-actions%2Fchanged-file...
Every action gets these permissions by default. The reason we know it had that permission is that the exploit code read from /proc/pid/mem to steal the secrets, which requires some permissions: https://blog.cloudflare.com/diving-into-proc-pid-mem/#access...
Linux processes have tons of default permissions that they don't really need.
Re: How to harden GitHub Actions
#43This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
GitHub Actions by default provide isolated VM with root privilege to a workflow. Don’t think job level privilege isolation is in its threat model currently. Although it does allow job level scopes for the default GitHub token. Also the secrets are accessible only when a workflow is invoked from trusted trigger ie. not from a forked repo. Not sure what else can be done here to protect against compromised 3rd party act…
People have been running different levels of privileged code together on the same machine ever since the invention of virtual machines. We have lots of lightweight sandboxing technologies that could be used when invoking a particular action such as tj-actions/changed-files that only gives it the permissions it needs.
You may do a "docker build" in a pipeline which does need root access and network access, but when you publish a package on pypi, you certainly don't need root access and you also don't need access to the entire internet, just the pypi API endpoint(s) necessary for publishing.
Re: How to harden GitHub Actions
#44I feel like there was a desire from GH to avoid needing a "build" step for actions so you could use `use: someones/work` or whatever, `git push` and see the action run.
But if you think about it, the entire design is flawed. There should be a `gh lock` command you can run to lock your actions to the checksum of the action(s) your importing, and have it apply transitively, and verify those checksums when your action runs every time it pulls in remote dependencies.
That's how every modern package manager works - because the alternative are gaping security holes.
Re: How to harden GitHub Actions
#45After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version https://github.com/santrancisco/pmw It has a few "features" which allowed me to go through a repository quickly: - It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code…
This is good, just bear in mind that if you put the hash of an external composite action and that action pulls on another one without a hash, you're still vulnerable on that transitive dependency.
Re: How to harden GitHub Actions
#46Earlier quoted context omitted.
never update
I can confirm there's real wisdom in this approach, lol. Nothing bad had happened to me for a while so I decided to update that one computer to ubuntu noble and YUP, immediately bricked by some UEFI problem. Ok cool, it's not like 2004 anymore, this will probably be a quick fix.. 3 hours later...
An OS upgrade broke UEFI. Huh? That doesn't sound right.
Re: How to harden GitHub Actions
#47After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version https://github.com/santrancisco/pmw It has a few "features" which allowed me to go through a repository quickly: - It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code…
I don't know if your tool already does this but it would be helpful if there is an option to output the version as a comment of the form
action@commit # semantic version
Makes it easy to quickly determine what version the hash corresponds to. Thanks.
Re: How to harden GitHub Actions
#48Step Security has a useful tool that aids in securing GitHub Actions here: https://app.stepsecurity.io/securerepo
Disclaimer: No conflict of interest just a happy user.
Re: How to harden GitHub Actions
#49GHA Newbie here: what are all these 3rd-party actions that people are using? How complicated is your build / deployment pipeline that you need a bunch of premade special steps for it?
Surely it's simple: use a base OS container, install packages, run a makefile.
For deployment, how can you use pre-made deployment scripts? Either your environment is bespoke VPS/on-prem, In which case you write your deployment scripts anyway, or you use k8s and have no deployment scripts. Where is this strange middleground where you can re-use random third party bits?
Re: How to harden GitHub Actions
#50After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version https://github.com/santrancisco/pmw It has a few "features" which allowed me to go through a repository quickly: - It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code…
I've been using https://github.com/stacklok/frizbee to lock down to commit hash. I wonder how this tool compares to that.