Hacker News Reader

Comment by sytse | Hacker News Reader

Even when you have control of a project tested by the CI server you should not have control of the CI server itself.

GitLab comes with integrated CI. But all the tests are ran by GitLab Runner on external machines. You can spin up (and down) a new machines per test with Runner Autoscale if you want.

As far as I could see GitLab CI is not vulnerable to the items mentioned in the article (apart from only enforcing password length, not complexity).

But CI security is hard so if you find anything please let us know https://about.gitlab.com/disclosure/

View on HN

Yes, sandboxing and ephemeral machines are far and away the best defense a CI system has against compiling/testing malicious code. But the vast majority of CI systems don't actually use ephemeral executors because imaging between runs is slow and rebuilding your whole checkout/object cache is expensive.

You don't need to own the CI server in order to own a project. You can take over all of the individual executors and replace their linker with your own version that links against an attacker-supplied backdoored fork of openssl (for an extreme and topical example). Doesn't even require constantly-running code which might be detected by a monitoring system, and naturally persists across reboots (but not reimagings).

I'm glad that GitLab is paying attention to these things. The Travis which is tightly integrated with GitHub also seems to do a good job, although I haven't looked into it extensively. But plenty of orgs run self-hosted CI that simply isn't up to proper security standards in this respect.

Rebuilding is expensive. We have several caching mechanisms but there is no silver bullet and caching itself can lead to security problems.

For a deeper review of security problems we're currently focussed on please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 and please feel free to contribute there.

For a discussion on caching and artifacts, please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21913.

Heavy Gitlab CI user here. The real problem is isolating the runners themselves. You can assign runners to individual projects for isolation, but when the runners can't be AWSed (iOS hardware, for example) you have to make tough choices about buying more stuff to sit under your desk right next to the stuff you could be using that's idle.

IMO some basic isolation measures like clearing the cache between projects would be good. Killing active processes when a job ends.

Thanks for using GitLab heavily! When running GitLab Runner on metal you can already opt to start with a fresh clone instead of updating I think. I'm not sure about killing active processes, feel free to create an issue to discuss further.

Reply on news.ycombinator.com