Sandboxing install-time code execution

[jscheid]

In the wake of Sha1 Halud much of the discussion has centered around cooldown, but I'm looking to address another aspect of package installation, that of install-time code execution.

I'm wondering about the feasibility of implementing something like bundle update|install --cache-only, which would work similarly to bundle cache --no-install except that it would first perform any version resolution.

Critically, the new --cache-only flag would guarantee that no code contained inside any gem (part of the bundle) would be executed yet. It would only download the package(s) into the vendor location from where they can later be installed with bundle install --local.

This scheme would have two immediate benefits:

1. Finalizing the installation could be run with reduced privileges, i.e. in a sandbox. This would allow removing package registry credentials from the env and disabling network access, since both are usually not needed outside of package download. ¹
2. It would simplify and make more reliable a comparison (audit) of old vs new gem contents; if the --cache-only command would write a tentative Gemfile.lock (maybe Gemfile.cache.lock) then a tool could show a full diff of exactly the changes that bundle install would apply.

It would ideally be possible to configure things (using bundle config) so that two-step upgrades and installations are enforced, i.e. so that bundle update|install without --cache-only flag fails when run outside a sandbox. This could be achieved through a customizable script that might ensure certain env vars are absent or pinging a given host fails.

Finally, ideally only gems on an allowlist would be permitted to execute code at all during installation.

Needless to say none of this would protect against malicious runtime code, aside from simplifying audits, but still be valuable seeing that install-time and runtime environments can differ, with different threat models.

Footnotes

1. I'd expect that some gems would fail to install without network access, but that could be addressed separately in the affected gems. ↩

[tenderlove]

I think this makes sense. It's kind of unfortunate, but this function tightly couples download and installation. I would like to separate those two things at some point so that we can download in parallel with installation.

That said, it looks like the function will return early if the no_install setting is set, which should do what you want. I think the main problem is that we don't have a way to get that option set via bundle install / bundle update (afaict).