Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing GitHub Actions policies in the dumbest way possible

blog.yossarian.net

Post reply on HN
Print view View original

51–60 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#51

Post by nyc1983 »

woodruffw wrote: post #47
nyc1983 wrote: post #44

[flagged]

Of the many things people have accused me of, being uninformed about GitHub Actions best practices is new. (CODEOWNERS is a red herring: GitHub clearly intends for this policy mechanism to be used, and so it should be sound. Policy mechanisms should always be sound, even if there's a better or more general alternative mechanism. If GitHub intends CODEOWNERS to be that mechanism, then they should remove this one and d…

Frankly I think your article focuses on an outdated or not relevant setting in GitHub. So the red herring is probably backwards here. There are tons of these (don’t get me started about topics and managing them for many repos), but GitHub has clearly been pushing rulesets over the past years and combined with CODEOWNERS this is the de-facto way of granularity managing who can make changes to GA workflows.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#52

Post by woodruffw »

nyc1983 wrote: post #51
woodruffw wrote: post #47

Earlier quoted context omitted.

Of the many things people have accused me of, being uninformed about GitHub Actions best practices is new. (CODEOWNERS is a red herring: GitHub clearly intends for this policy mechanism to be used, and so it should be sound. Policy mechanisms should always be sound, even if there's a better or more general alternative mechanism. If GitHub intends CODEOWNERS to be that mechanism, then they should remove this one and d…

Frankly I think your article focuses on an outdated or not relevant setting in GitHub. So the red herring is probably backwards here. There are tons of these (don’t get me started about topics and managing them for many repos), but GitHub has clearly been pushing rulesets over the past years and combined with CODEOWNERS this is the de-facto way of granularity managing who can make changes to GA workflows.

Unlike other things that have been moved to rulesets, there's no prominent marker on these policies indicating that they're outdated or no longer considered best practice. Do you have some kind of public indication that these are discouraged in any way?

(As others have pointed out, this isn't even necessarily something that makes sense with CODEOWNERS -- the point of a dependency policy is to not trust human identities at all.)

Re: Bypassing GitHub Actions policies in the dumbest way possible

#53

Post by solatic »

If your Security folk are trying to draw up a wall around the enterprise (prevent using stuff not intentionally mirrored in) but there are no network controls - no IP address based firewalls, no DNS firewalls, no Layer 7 firewalls (like AWS VPC Endpoint Policy or GCP VPC Service Controls) governing access to object storage and the like.... Quite frankly, the implementation is either immature or incompetent.

If you work for an org with restrictive policy but not restrictive network controls, anyone at work could stand up a $5 VPS and break the network control. Or a Raspberry Pi at home and DynDNS. Or a million others.

Don't be stupid and think that a single security control means you don't need to do defense in depth.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#54

Post by OptionOfT »

We forked the actions as a submodule, and then pointed the uses to that directory.

That way we were still tracking the individual commits which we approved as a team.

Now there is interesting dichotomy. On one hand PMs want us to leverage GitHub Actions to build out stuff more quickly using pre-built blocks, but on the other hand security has no capacity or interest to whitelist actions (not to mention that the whitelist list is limited to 100 actions as per the article).

That said, even tagging GitHub actions with a sha256 isn't perfect for container actions as they can refer to a tag, and the contents of that tag can be changed: https://docs.github.com/en/actions/sharing-automations/creat...

E.g. I publish an action with code like

   runs:
     using: 'docker'
     image: 'docker://optionoft/actions-tool:v3.0.0'
You use the action, and pin it to the SHA of this commit.

I get hacked, and a hacker publishes a new version of optionoft/actions-tool:v3.0.0

You wouldn't even get a Dependabot update PR.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#55

Post by x0x0 »

TheTaytay wrote: post #26

I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.

The risk is the same reason we don't allow any of our servers to make outgoing network connections except to a limited host lists. eg backend servers can talk to the gateway, queue / databases, and an approved list of domains for apis and nothing else.

The same guard helps prevent accidents, not maliciousness, and security breaches. If code somehow gets onto our systems, but we prevent most outbound connections, exfiltrating is much harder.

Yes, people do code review but stuff slips through. See eg Google switching one of their core libs that did mkdir with a shell to run mkdir -p (tada! every invocation better understand shell escaping rules). That made it through code review. People are imperfect; telling your network no outbound connections (except for this small list) is much closer to perfect.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#56

Post by Already__Taken »

monster_truck wrote: post #19

Had these exact same thoughts while I was configuring a series of workflows and scripts to get around the multiple unjustified and longstanding restrictions on what things are allowed to happen when. That sinking feeling when you search for how to do something and all of the top results are issues that were opened over a decade ago... It is especially painful trying to use github to do anything useful at all after be…

I'm baffled you can't clone internal/private repos with anything other than a developer PAT. They have a UI to share access for workflows, let cloning use that...

Re: Bypassing GitHub Actions policies in the dumbest way possible

#57

Post by saghm »

monster_truck wrote: post #19

Had these exact same thoughts while I was configuring a series of workflows and scripts to get around the multiple unjustified and longstanding restrictions on what things are allowed to happen when. That sinking feeling when you search for how to do something and all of the top results are issues that were opened over a decade ago... It is especially painful trying to use github to do anything useful at all after be…

It used 1.8 days of time to run for a single day? I'm less curious about who's paying for it than who's _using _ it on your repo, because I can't even imagine having an average of almost two people scanning a codebase every single minute of the day.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#58

Post by masklinn »

bob1029 wrote: post #27

I feel like GitHub's CI/CD offering is too "all-in" now. Once we are at a point where the SCM tool is a superset of AWS circa 2010, we probably need to step back and consider alternatives. A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks. I would much rather write CI/CD to…

> A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks.

That... has existed for years? https://docs.github.com/en/rest?apiVersion=2022-11-28

That was the only thing available before github actions. That was also the only thing available if you wanted to implement the not rocket science principle before merge queues.

It's hard to beat free tho, especially for OSS maintainership.

And GHA gives you concurrency you'd have to maintain an orchestrator (or a completely bespoke solution), just create multiple jobs or workflow.

And you don't need to deal with tokens to send statuses with. And you get all the logs and feedback in the git interface rather than having to BYO again. And you can actually have PRs marked as merged when you rebased or squashed them (a feature request which is now in middle school: https://github.com/isaacs/github/issues/2)

> PRs are hardly latency sensitive, so polling a REST API once every 60 seconds seems acceptable to me.

There is nothing to poll: https://docs.github.com/en/webhooks/types-of-webhooks

Re: Bypassing GitHub Actions policies in the dumbest way possible

#59

Post by [deleted] »

ghusto wrote: post #11

> world’s dumbest policy bypass: instead of doing uses: actions/checkout@v4, the user can git clone (or otherwise fetch) the actions/checkout repository into the runner’s filesystem, and then use uses: ./path/to/checkout to run the very same action Good lord. This is akin to saying "Instead of doing `apt-get install `, one can bypass the apt policies by downloading the package and running `dpkg -i `.

[deleted]
Post reply on HN