wiki/src/blueprint/Linux_containers.mdwn

   1 **Corresponding tickets**: [[!tails_ticket 6178]] and friends.
   2
   3 [[!toc levels=2]]
   4
   5 Background
   6 ==========
   7
   8 Tails currently [[uses only AppArmor for isolating
   9 applications|contribute/design/application_isolation]].
  10
  11 User namespaces eventually made their way into the 3.8 kernel:
  12 <https://lwn.net/Articles/531114/>.
  13
  14 Threat model
  15 ============
  16
  17 These are *potential* goals. It remains to be discussed which ones are
  18 MUST, SHOULD, etc., which can vary depending on the
  19 sandboxed application.
  20
  21 * filesystem isolation?
  22 * X isolation? (e.g. key logging, taking pictures of the screen)
  23 * network isolation?
  24 * privilege escalation via holes in Linux?
  25 * privilege escalation via already running privileged daemons, or
  26   setuid/setgid binaries?
  27 * isolation from hardware?
  28   - sound: prevent sandboxed software from recording
  29   - identifiers: prevent sandboxed software from learning hardware
  30     identifiers, e.g. the MAC address; probably hard to achieve, since
  31     containers share the host's kernel
  32
  33 Security limitations
  34 ====================
  35
  36 * Until we can use Ubuntu's AppArmor profiles for LXC in Debian (most
  37   notably, the mount mediation support is missing), privileged
  38   containers still [seem to be
  39   unsafe](https://www.stgraber.org/2014/01/01/lxc-1-0-security-features/).
  40 * [Unprivileged
  41   containers](https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/)
  42   should be enough for most of what we intend to contain. It's unclear
  43   if they can be made to work on Debian Wheezy (seems to require quite
  44   some backporting work). Note, however, that unprivileged containers
  45   have had quite some security issues when they were introduced (and
  46   for this reason, the grsec patchset disables unprivileged use of
  47   user namespaces). Have things gotten better since?
  48
  49
  50 Tools to manage containers
  51 ==========================
  52
  53 * LXC
  54 * `unshare(1)`
  55 * [pflask](https://github.com/ghedo/pflask) automates the creation of
  56   simple Linux containers based on them; it is e.g. used by
  57   [pflask-debuild](https://github.com/ghedo/pflask/blob/master/tools/pflask-debuild)
  58 * systemd-nspawn
  59 * Docker, that we're [[evaluating|blueprint/evaluate_Docker]] as
  60   a candidate to replace Vagrant in our easy build system
  61
  62 Running GUI applications in containers
  63 ======================================
  64
  65 We're told that Subgraph OS will use LXC + xpra. In this vein:
  66
  67 * <http://pleonasm.info/blog/2012/10/privilege-separation-with-xpra/>
  68 * [docker-desktop](https://github.com/rogaha/docker-desktop)
  69 * Stéphane Graber's [LXC 1.0 blog post
  70   series](https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/),
  71   and especially [GUI in
  72   containers](https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/)
  73 * <https://unix.stackexchange.com/questions/134939/x-and-xdotool-in-lxc-instead-of-kvm>
  74 * <https://stackoverflow.com/questions/16296753/can-you-run-gui-apps-in-a-docker>
  75
  76 Other resources
  77 ===============
  78
  79 * <http://doger.io/> documents in details the current state of Linux
  80   containers (namespaces) and of the various userspace implementations
  81 * [Docker, Linux Containers (LXC), and
  82   security](http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security):
  83   good summary of the threats and solutions, as of August 2014
  84 * [Linux Container Security](http://mjg59.dreamwidth.org/33170.html),
  85   by Matthew Garrett