News for hackers. Stuff that matters.
Re:We Executed a Critical Supply Chain Attack on PyTorch by ethbr1 on Sunday January 14, 2024 @04:15PM (#38994506)
What's the GitHub Actions tooling like for emphemeral self-hosted runners?

Afaict, a huge portion of this attack came from persistence on the self-hosted runner.

Absent that, they would have needed a container jailbreak as well, which substantially ups the difficulty.

And if a repo is running <100 builds a day, spin up + kill container seems a small per-build price to pay for the additional security isolation.

Re:We Executed a Critical Supply Chain Attack on PyTorch by jackwilsdon on Sunday January 14, 2024 @04:19PM (#38994540)
GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it).

https://docs.github.com/en/actions/hosting-your-own-runners/...

Re:We Executed a Critical Supply Chain Attack on PyTorch by gz5 on Sunday January 14, 2024 @05:34PM (#38995126)
there are 3rd party foss options (1):

1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-we...

2. zero implicit trust: https://github.com/openziti/ziti-webhook-action

(1) disclosure, maintainer (2) zero implicit trust in this case = no open inbound ports on underlay; need to access via app-specific overlay which requires strong identity, authN, authZ

Re:We Executed a Critical Supply Chain Attack on PyTorch by crohr on Monday January 15, 2024 @03:07AM (#38998456)
I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public.

[1]: https://runs-on.com

Re:We Executed a Critical Supply Chain Attack on PyTorch by withinboredom on Tuesday January 16, 2024 @12:24PM (#39015944)
The default kubernetes implementation owned by github[1] assumes ephemeral runners by default. You can also specify what policies they should have using regular network policies provided by kubernetes. So, if you have a kubernetes cluster, that's the way to go.

[1]: https://github.com/actions/actions-runner-controller