From 46d4438cc4409ab648409bc6dcfdc4eb965a420d Mon Sep 17 00:00:00 2001 From: "Kartik K. Agaram" Date: Sat, 25 Dec 2021 08:59:46 -0800 Subject: 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. --- sandboxing/README.md | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'sandboxing/README.md') 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 -- cgit 1.4.1-2-gfad0