Build dependency sanitization (in particular build.rs files)

[bunnie]

Xous relies on some dependencies from crates.io. Separate from the issue of reviewing the code itself, there is the issue that every crate has an opportunity to pull in a build.rs file, which is essentially the equivalent of downloading and running a collection of random shell scripts on your local machine with your personal credentials.

A quick look around reveals there doesn't seem to be any really good tools to help manage this or to check what these scripts are doing.

It'd be nice to have a tool or methodology that does something like the following:

1. Trawls the Cargo.lock file at a particular tag or release using e.g. cargo vendor for build.rs scripts
2. Enumerates all the scripts that could run and either
3. Provides an easy interface for developers to sign-off and review the scripts, so we can have a way to transfer burden of reviewing the scripts to trusted community members, and also provides a native interface to warn when said scripts change; or
4. Provides an automated way to review scripts for commands and idioms that would be on a list of hazardous operations (or perhaps the inverse, rubber-stamp simple script that only use a limited set of known-safe operations, and flag out for further review ones that do things which aren't easy to automatically analyze)

A brief look at the build.rs files we currently depend upon reveal that most of them do things like check the target triple, point to an XML file for config, or the likes.

But there is also no reason someone couldn't put into a build.rs script a shell operation that takes the contents of your ~/.ssh directory and slings them to a remote server. We'd like to have some evidence-based assurance that is not happening; or at the very least, have a sense of how big of an attack surface we need to worry about from this standpoint.

[bunnie]

There's a simple script now that downloads all the dependencies required to build Xous, and collates all the build.rs files into a single mega-file for easier review.

There's...a lot...of code that gets run on your machine to build things. Kind of distressing, tbh: I get why it's necessary, as cross-platform builds are really hard, but this is just a huge attack surface for injecting code that gets run on your build machine. I totally sympathize with developers in security who think this is an opsec disaster, because it kind of is.

[philips]

There are some good thoughts on this problem in the Android + Rust blog post as well: https://security.googleblog.com/2021/05/integrating-rust-into-android-open.html

[bunnie]

Interesting. I'm glad to see there are others also worrying about this.

We are still grappling with the problem and in the short term perhaps the only practical solution for us is to create a virtual machine or container image that runs the build, and consider the VM and/or container to be an integral part of the software supply chain.