Hacker News Reader

Comment by nextaccountic | Hacker News Reader

Makefiles too. And any npm or pypi package. And also maven. Those things run arbitrary code that can access your ssh keys and upload malware to Github under your name (among other things). This has happened before.

Securing just proc macros doesn't really make builds secure because there is build.rs too, and other build tools besides Cargo.

Truth is, if you want to protect yourself, you need to build in a VM, AND run the binary in a VM. Regardless of the language, that's not specific to Rust.

View on HN

> Truth is, if you want to protect yourself, you need to build in a VM, AND run the binary in a VM. Regardless of the language, that's not specific to Rust.

I have been in the practice of running build scripts/package installers in a container for projects that I don't explicitly trust for a while now. I wish more people saw the value in doing so.

I used to build everything in my homedir as well until about 6-7 years ago when there was a big outbreak of malware scripts on NPM. Quickly realized the folly of running so much untrusted code with the same privileges that I use to do everything short of administrating my machine.

This protects your machine but not necessarily the resulting binary code. Nothing prevents the malware from patching the source before building and removing the patch before the end, resulting in a binary and a package that contain code that doesn't match your trusted sources.

As a general rule, it must always be possible to build without network access, otherwise you're having a big trust problem. And once you know you're having all your dependencies, only then you can think about sandboxing all this stuff after having carefully studied it.

In many (but not all) Linux package distributions, malware is filtered out by maintainers. In other package distributions, maintainers are omitted, because «it's too hard». Instead, everybody protects it's own system alone.

Even if your ssh-key will not be stolen when project is built, it still can happen when malware will be shipped to your client. How you protect your client?

Please remember that by default running in a container (docker) is not secure. Unfortunately you need to invest some time and brainpower to improve security.

For what reasons specifically? Namespaces not being good enough (if the malware is more complex and tries to exploit the kernel)?

> Regardless of the language

Haskell has Safe Haskell, where there is no way (at compile-time or at runtime) to "sneakily" violate user expectations. In particular, any compile-time IO is disabled and any runtime IO must be clearly marked.

This is not true for Maven and overall the general Java ecosystem. Your own build may have arbitrary logic, true (this holds for Maven, Gradle, SBT - virtually any build tool for JVM), but the artifacts which are distributed to consumers of libraries never have anything which gets automatically executed by the build process of the consumer. build.rs and equivalents, however, are a part of the package itself and are executed when the package is “depended on”.

> but the artifacts which are distributed to consumers of libraries never have anything which gets automatically executed by the build process of the consumer

What if I build everything from source, including all libraries? (That is, do not consume any .jar files but build them myself). I would surely need to run the build step of every library right?

And you must never again attach that VM/container to the network/internet if it had access to sensitive information at the time of running the untrusted code.

What about Guix ?

It looks like you can sandbox builds with guix, and this appears to be the default. But I can only find a single configuration line here https://guix.gnu.org/manual/en/html_node/Miscellaneous-Servi... (ctrl+f sandbox)

It's based off Nix sandboxing https://nixos.wiki/wiki/Nix_package_manager#Sandboxing

> When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of fetch* functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see nix.conf section in the Nix manual for details.

> Sandboxing is enabled by default on Linux, and disabled by default on macOS. In pull requests for Nixpkgs people are asked to test builds with sandboxing enabled (see Tested using sandboxing in the pull request template) because in official Hydra builds sandboxing is also used.

> To configure Nix for sandboxing, set sandbox = true in /etc/nix/nix.conf; to configure NixOS for sandboxing set nix.useSandbox = true; in configuration.nix. The nix.useSandbox option is true by default since NixOS 17.09.

This appears to use namespaces etc (basically containers) rather than a VM but I think it may be secure. Their goal is to aid reproducibility but if the network isolation actually works, then at least the build will be secure.

Note that an infected source may either run malware during build, or embed malware in the compiled binary (or both). When running the binary you're not protected at all by this sandboxing, unless you use something like Qubes (which is quite heavyweight)

Guix builds are sandboxed per package (I'm pretty sure it cannot be turned off at all). The Guix build containers don't have network access.

Guix package definitions include a cryptographic hash of the source, don't autoupdate and have people review when there is an update.

The Guix package definition includes what dependent packages this package needs. These dependencies will be built first and the result made available for the Guix container of the final package build. Nothing else is available in there.

Reply on news.ycombinator.com