Problem

There is a risk of malicious code inserted into our specification tests.

We wish to be able to run Updoc tests, testing every aspect of an E implementation, such that they can do no harm (beyond stopping the test suite from finishing, or making its output invalid).

The E-on-JavacmdLoop has a confinement option, but it takes away all privilegedEnv elements, so the tests could not test streams, files and so on. E-on-CL provides a slightly larger set, but still does not provide file access.

In general, we want to provide an environment that looks as close to the standard privileged environment as practical, but is actually completely confined — and yet still allows the tests to exercise as much of the implementation as practical.

Proposal

Given these constraints, the obvious solution is to make every privilegedEnv authority virtualizable. Here is a review of the privileged environment as implemented in E-on-Java (as of r802, 2011-02-08).

Messier virtualization strategies

Option 2: Allow full access — we're not trying to bit-confine the tests, after all. Maybe prohibit LAN access — this would be generally useful as a security policy. "The Internet in general, but nothing local"

Option 3: Allow test code to talk among itself only.

stdin — This will be determined by how the test suite goes about testing stdin.