This model concerns itself with running a build locally. Some terminology:

• project – what is being built
• host – the computer where Ambient is run

Many software projects require running code from that project to be built, and certainly when it’s automated tests are run. The code might not be directly part of the project, but might come from a dependency specified by the project. This code can do anything. It might be malicious and attack the build host. It probably doesn’t, but Ambient must be able to safely and securely build and test projects that aren’t fully trusted and trustworthy.

The attacks we are concerned with are:

• reading, modifying, or storing data on the host, in unexpected ways
• using too much CPU on the host
• using too much memory on the host
• using too much disk space on the host
• accessing the network from the host, in unexpected ways
• leaking secrets (passwords, encryption keys) from the host

Prevention

We build and test in a local virtual machine.

The VM has no network access at all. We provide the VM the project source code via a read-only virtual disk. We provide the VM with another virtual disk where it can store any artifacts that should persist. Both virtual disks will contain no file system, but a tar archive.

We provide the VM with a pre-determined amount of virtual disk. The project won’t be able to use more.

We provide the VM with an operating system image with all the dependencies the project needs pre-installed. Anything that needs to be downloaded from online repositories is specified by URL and cryptographic checksum, and downloaded before the VM starts, and provided to the build via a virtual disk to the VM.

We interact with the VM via a serial console only.

We run the VM with a pre-determined amount of disk, number of CPUs, amount of memory. We fail the build if it exceeds a pre-determined time limit. We fail the build if the amount of output via the serial console exceeds a pre-determined limit.