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

61–70 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#61

Post by hk1337 »

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.

I haven't tested this but the main risk that is possible is users creating PRs on public repositories with actions that run on pull request.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#62

Post by masklinn »

woodruffw wrote: post #29
lixtra wrote: post #28

Earlier quoted context omitted.

It’s like putting curl -sSL https://example.com/install.sh | sh In your action. For sure happens.

Yes; I would also consider that a bad idea. Two wrongs don't make a right (and a different wrong doesn't justify a broken policy elsewhere).

Being able to filter or disable network access (aside from what github requires on their side to interact with actions) would definitely be useful, but AFAIK that's only an option for self-hosted runners and enterprise accounts.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#63

Post by opello »

OptionOfT wrote: post #54

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 white…

Maybe there's a future Dependabot feature to create FYI issues when in use tags change?

Re: Bypassing GitHub Actions policies in the dumbest way possible

#65

Post by woodruffw »

masklinn wrote: post #62
woodruffw wrote: post #29

Earlier quoted context omitted.

Yes; I would also consider that a bad idea. Two wrongs don't make a right (and a different wrong doesn't justify a broken policy elsewhere).

Being able to filter or disable network access (aside from what github requires on their side to interact with actions) would definitely be useful, but AFAIK that's only an option for self-hosted runners and enterprise accounts.

Yep, I agree completely. It's unfortunate that self-hosted runners are otherwise so difficult to secure, since controlled ingress/egress is otherwise an extremely strong motivation for using them.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#66

Post by throwaway52176 »

Already__Taken wrote: post #56
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...

I use GitHub apps for this, it’s cumbersome but works.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#67

Post by zingababba »

Copilot repository exclusions is another funny control from GitHub. It gets the local repo context from the .git/config remote origin URL. Just comment that out and you can use copilot on an 'excluded' repo. Remove the comment to push your changes. Very much a paper control.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#68

Post by jand »

hk1337 wrote: post #18

This is why I avoid using non-official actions where possible and always set a version for the action. We had a contractor that used some random action to ssh files to the server and referenced master as the version to boot. First, ssh isn't that difficult to upload files and run commands but the action owner could easily add code to save private keys and information to another server. I am a bit confused on the "byp…

> I am a bit confused on the "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository?

I understand it that way, too. But: Having company-wide policies in place (regarding actions) might be misunderstood/used as a security measure for the company against malicious/sloppy developers.

So documenting or highlighting the behaviour helps the devops guys avoid a wrong sense of security. Not much more.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#70

Post by welshwelsh »

kj4ips wrote: post #6

This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…

Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea.

Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

Post reply on HN