Skip to content

GitLab

Last edited by intrigeri
Page history

Linux_containers

Corresponding tickets: tails#6178 (closed) and friends.

Background

Tails currently uses only AppArmor for isolating applications.

User namespaces eventually made their way into the 3.8 kernel: https://lwn.net/Articles/531114/.

Threat model

These are potential goals. It remains to be discussed which ones are MUST, SHOULD, etc., which can vary depending on the sandboxed application.

  • filesystem isolation?
  • X isolation? (e.g. key logging, taking pictures of the screen)
  • network isolation?
  • privilege escalation via holes in Linux?
  • privilege escalation via already running privileged daemons, or setuid/setgid binaries?
  • isolation from hardware?
    • sound: prevent sandboxed software from recording
    • identifiers: prevent sandboxed software from learning hardware identifiers, e.g. the MAC address; probably hard to achieve, since containers share the host's kernel

Security limitations

  • Until we can use Ubuntu's AppArmor profiles for LXC in Debian (most notably, the mount mediation support is missing), privileged containers still seem to be unsafe.
  • Unprivileged containers should be enough for most of what we intend to contain. Note, however, that unprivileged containers have had quite some security issues when they were introduced (and for this reason, the grsec patchset disables unprivileged use of user namespaces). Have things gotten better since?

Tools to manage containers

  • LXC
  • unshare(1)
  • pflask automates the creation of simple Linux containers based on them; it is e.g. used by pflask-debuild
  • systemd-nspawn
  • Docker, that we're evaluating as a candidate to replace Vagrant in our easy build system

Running GUI applications in containers

Subgraph's Oz

  • Oz is a sandboxing system targeting everyday workstation applications. It relies mainly on Xpra and Linux namespaces.
  • See its technical documentation for details.
  • It has a GNOME Shell extension that e.g. allows one to add files (read-only or read-write) to a running sandbox.
  • Sandboxed applications can optionally be given access to:
    • files passed on their command line (in a read-only manner), which makes them work just fine when started e.g. from a file manager or a web browser;
    • the microphone and/or speaker, thanks to Xpra.
  • Potential functionality limitations and UX issues:
    • It's not clear to me how things such as copy'n'pasting between applications, printing, Orca and IBus input methods are handled. Some of those need access to the session D-Bus, so presumably making these work will require mediating D-Bus calls, as done e.g. in AppArmor on Ubuntu.
      • Xpra 0.14+ can be set up to configure IBus, but how does this integrate with the IBus configuration changes applied via the desktop environment?
      • Xpra 0.15+ provides a CUPS forwarder backend
    • When one has already started e.g. LibreOffice and needs to open a new file, they need to first use the GNOME Shell extension to add it to the sandbox; in this respect, the resulting UX seems to be inferior to the one the designs the AppArmor and xdg-app folks mean to implement (file chooser with a privileged backend). Creating new files might be problematic as well.
    • Most host OS directories are bind-mounted (read-only) inside the sandbox, and a blacklist is applied on top. This means that arbitrary code execution is possible, but confined within the sandbox, while with AppArmor we restrict a bit more what external programs can be executed, but the equivalent of the sandbox is arguably weaker.
    • Xpra doesn't support Wayland yet, and Wayland will make some of Xpra's current advantages obsolete.

Other GUI in containers leads

Other resources