Virtualized privileged environment
From Erights
Contents |
Problem
- The shall include Updoc tests.
- The chosen location for our E platform specification.
- Wikis are editable by many people.
Therefore,
- 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-Java cmdLoop 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).
Completely obvious virtualization strategies
- stdout, stderr, print, println, interp — these are already virtualized/implemented by updoc/cmdLoop
- currentVat — might want to review Vat's authority grants
- privilegedScope — refers to itself
These are defined in terms of other privileges in ScopeSetup, so they will be automatically virtual:
- makeSturdyRef
- timeMachine
- rune — Defined in terms of <unsafe>
- swtWatch
Reasonable virtualization strategies
Messier virtualization strategies
- <jar> — XXX
- <http>, <ftp>, <gopher>, <news>, <captp>/introducer/identityMgr
- Option 1: Allow access to network, but restricted hosts.
- 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.
Impossible by definition
However, these cannot be tested by untrusted test files anyway:
Tricky cases
- makeCommand (shell command/subprocess invocation)
