sandbox: another scenario, some UX ideas

I'd originally thought of allowing policies to be influenced by
arbitrary code. But that may be overkill:
  - it's probably not a good idea to allow policies to read/write from file system
  - it's even less a good idea to allow policies to access the network
    - particularly since it's difficult (error-prone) to distinguish GET/POST in arbitrary protocols
  - once you allow file system and network, you're pretty close to owned

So let's first focus on the simplest policy, the one that is easiest to
secure. We'll add capabilities to policies as we gain confidence we can
secure them.

1 files changed, 8 insertions, 0 deletions

diff --git a/sandboxing/README.md b/sandboxing/README.md
index b816927..3c74dbd 100644
--- a/sandboxing/README.md
+++ b/sandboxing/README.md
@@ -21,6 +21,9 @@ string path or url to a file descriptor.
 Scenarios:
   * (1) app reads system files
   * (1) app sends data to a remote server
+  * (1) app should _never_ be allowed to open Teliva's system files:
+      - `teliva_editor_state`
+      - app-specific sandboxing policies
   * (2) app can read from a remote server but not write (POST)
   * app gains access to a remote server for a legitimate purpose, reads
     sensitive data from the local system file for legitimate purpose. Now
@@ -37,6 +40,11 @@ Difficulty levels
   2. Seems vaguely doable.
   3. Seems unlikely to be doable.
 
+UX:
+  * easily visualize how secure a configuration is.
+    - maybe show a lock in halves; left half = file system, right half =
+      network. One half unlocked = orange. Both unlocked = red.
+
 ## Bottom up
 
 * `includes`: all `#include`s throughout the codebase. I assume that C the