Virtualized privileged environment

From Erights

Contents 1 Problem 2 Proposal 2.1 Completely obvious virtualization strategies 2.2 Reasonable virtualization strategies 2.3 Messier virtualization strategies 2.4 Impossible by definition 2.5 Tricky cases 2.6 GUI authorities

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

• <file>, <fileURL> — Opaque file objects

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:

• <unsafe>

Tricky cases

• makeCommand (shell command/subprocess invocation)

GUI authorities

• <awt>
• <swing>
• <JPanel>
• <swt>
• currentDisplay
• swtGrid__quasiParser