**Corresponding tickets**: [[!tails_ticket 6178]] and friends.
Tails currently [[uses only AppArmor for isolating
User namespaces eventually made their way into the 3.8 kernel:
These are *potential* goals. It remains to be discussed which ones are
MUST, SHOULD, etc., which can vary depending on the
* 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
* 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
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](https://github.com/ghedo/pflask) automates the creation of
simple Linux containers based on them; it is e.g. used by
* Docker, that we're [[evaluating|blueprint/evaluate_Docker]] as
a candidate to replace Vagrant in our easy build system
Running GUI applications in containers
## Subgraph's Oz
* [Oz](https://github.com/subgraph/oz) is a sandboxing system targeting
everyday workstation applications. It relies mainly on Xpra and
* See its [technical
* It has a [GNOME Shell
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
* 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
- Xpra doesn't support Wayland yet, and Wayland will make some of
Xpra's current advantages obsolete.
## Other GUI in containers leads
* [Subuser](http://subuser.org/): essentially Docker + Xpra
* [GNOME sandboxed
Flatpak (formerly `xdg-app`); their concept of "portals" is very interesting.
- [GNOME Developer Experience hackfest: xdg-app + Debian](http://smcv.pseudorandom.co.uk/2016/xdg-app/)
- LWN on [An initial release of Flatpak portals for GNOME](https://lwn.net/Articles/694291/)
- [The flatpak security model – part 1: The basics](https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/)
- [The flatpak security model – part 2: Who needs sandboxing anyway?](https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/)
- [The flatpak security model, part 3 – The long game](https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/)
* Ubuntu Snap
- LWN on [Snap interfaces for sandboxed applications](https://lwn.net/Articles/694757/),
comparing them to Flatpack's portals
* Stéphane Graber's [LXC 1.0 blog post
and especially [GUI in
* <http://doger.io/> documents in details the current state of Linux
containers (namespaces) and of the various userspace implementations
* [Docker, Linux Containers (LXC), and
good summary of the threats and solutions, as of August 2014
* [Linux Container Security](http://mjg59.dreamwidth.org/33170.html),
by Matthew Garrett
* Whitepaper by NCC Group on [Linux containers](https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaperpdf/) and their weaknesses/strengths
* Google's design for [Linux containers](https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md) within ChromeOS