Corresponding tickets: tails#6178 (closed) and friends.
- Threat model
- Security limitations
- Tools to manage containers
- Running GUI applications in containers
- Other resources
Tails currently uses only AppArmor for isolating applications.
User namespaces eventually made their way into the 3.8 kernel: https://lwn.net/Articles/531114/.
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
- 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
- pflask automates the creation of simple Linux containers based on them; it is e.g. used by pflask-debuild
- Docker, that we're evaluating as a candidate to replace Vagrant in our easy build system
Running GUI applications in containers
- 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-appfolks 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.
- 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.
Other GUI in containers leads
- Subuser: essentially Docker + Xpra
xdg-app); their concept of "portals" is very interesting.
To monitor use of portals (e.g. to tell whether they're used at all), use
dbus-monitor. For example:
dbus-monitor --session "interface='org.freedesktop.portal.FileChooser'"
To force GTK to use Portals for select, supported APIs, even outside of Flatpak:
This works, for example, for the Open/Save file dialogs of Firefox 68 and gedit, and for the Print dialog of Evince. But it does not work for the Open/Save file dialogs of GIMP 2.10.8-2+b1 or Evince 3.30.2-3.
Ideally we would force usage of Portals for every AppArmor-confined application.
Flatpak'ing Tor Browser:
- AsciiWolf's initial work: https://github.com/micahflee/torbrowser-launcher/issues/407, https://github.com/flathub/flathub/pull/1135
- muelli's initial work: bug #25578 on Tor Project's Trac
- Ubuntu Snap
- Snap seems to be moving towards using Portals. For example, support for snaps was [added to xdg-desktop-portal]https://github.com/flatpak/xdg-desktop-portal/pull/155).
- LWN on Snap interfaces for sandboxed applications, comparing them to Flatpack's portals
- Stéphane Graber's LXC 1.0 blog post series, and especially GUI in containers
- http://doger.io/ documents in details the current state of Linux containers (namespaces) and of the various userspace implementations
- Docker, Linux Containers (LXC), and security: good summary of the threats and solutions, as of August 2014
- Linux Container Security, by Matthew Garrett
- Whitepaper by NCC Group on Linux containers and their weaknesses/strengths
- Google's design for Linux containers within ChromeOS