How It Works

  • Sandstorm's server-side sandboxing is based on the same underlying Linux kernel features as LXC and Docker. We use the system calls directly for finer-grained control.
  • (Planned) The kernel attack surface is reduced using seccomp-bpf to block and/or virtualize system calls.
  • procfs, sysfs, etc. are not mounted in the sandbox, and only a minimal set of devices are available.
  • (Planned) On the client side, apps run in a sandboxed iframe employing the Content-Security-Policy header to prevent them from sending any kind of network communication to any server other than their own.
  • All communication between the sandboxed server and the outside world takes place through a single Cap'n Proto RPC socket which the app's root process receives as file descriptor #3. We've provided a program, legacy-bridge, which can receive HTTP-over-RPC requests on this socket and proxy them to a regular HTTP server running in the sandbox.
  • Every object (e.g., each document) that you create with an application runs in a separate isolated sandbox. We sandbox per-object rather than per-app so that it is easy and safe to share one object without also sharing everything created using the same app.
  • An application package (.spk file) is essentially an archive containing an entire chroot environment in which the application runs.
  • The application runs with the contents of its package mounted read-only, so that multiple instances of the same app can share disk space for the package.
  • The application may store persistent state in the /var directory.
  • App servers are aggressively killed off as soon as the user closes the browser tab, then restarted when the user returns later.
  • Packages are cryptographically signed. Packages signed with the same key represent versions of the same app, and are thus allowed to replace older versions -- although the user must still confirm these upgrades.