Virtualized privileged environment

From Erights

Jump to: navigation, search



  • The shall include Updoc tests.
  • The chosen location for our E platform specification.
  • Wikis are editable by many people.


  • 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.


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

These are defined in terms of other privileges in ScopeSetup, so they will be automatically virtual:

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

GUI authorities

Personal tools
more tools