src/_posts/2018-07-04-bare-bone-containers-with-systemd-nspawn.md

   1 ---
   2 id: 733
   3 title: containers, e.g. with systemd
   4 date: 2018-07-04T15:41:13+00:00
   5 author: xro
   6 layout: post
   7 guid: http://wp.realraum.at/?p=733
   8 permalink: /2018/07/bare-bone-containers-with-systemd-nspawn/
   9 snap_isAutoPosted:
  10   - 1530711673
  11 responsive_meta_box_designation:
  12   -
  13 responsive_meta_box_facebook:
  14   -
  15 responsive_meta_box_twitter:
  16   -
  17 responsive_meta_box_googleplus:
  18   -
  19 responsive_meta_box_text_linkedin:
  20   -
  21 snap_MYURL:
  22   -
  23 snapEdIT:
  24   - 1
  25 snapTW:
  26   - 's:421:"a:1:{i:0;a:13:{s:2:"do";s:1:"1";s:10:"SNAPformat";s:15:"%TITLE% - %URL%";s:8:"attchImg";s:1:"1";s:9:"isAutoImg";s:1:"A";s:8:"imgToUse";s:0:"";s:4:"doTW";i:0;s:9:"msgFormat";s:15:"%TITLE% - %URL%";s:9:"isAutoURL";s:1:"A";s:8:"urlToUse";s:0:"";s:8:"isPosted";s:1:"1";s:4:"pgID";s:19:"1014504531030355968";s:7:"postURL";s:55:"https://twitter.com/realraum/status/1014504531030355968";s:5:"pDate";s:19:"2018-07-04 13:41:43";}}";'
  27 categories:
  28   - english
  29 tags:
  30   - randomthoughs
  31 ---
  32 The more complex a program or application, the more likely it contains exploitable or otherwise dangerous faults. Containers are a way of limiting the damage by limiting an application access to the bare minimum. Ideally we would have a separate and instantly replaceable computer for every little daemon and service we run. Sadly, even with virtual machines, this would hardly be an efficient use of resources, so containers try to find a middle ground by allowing us to separate applications almost as if they were running on different machines, while actually sharing the same hardware and operating system kernel.
  33
  34 ##### Several features come together to make this possible:
  35
  36   * chroot
  37   * namespaces
  38   * cgroups
  39
  40 #### And it is a good idea to augment them with others:
  41
  42   * seccomp-bpf syscall filter
  43   * packet filtering (ebtables)
  44   * virtual network devices
  45   * apparmor
  46
  47 Armed with these keywords, your week should now be filled with interesting and productive reading. :-)
  48
  49 If all you want are some opinionated basics however, read on:
  50
  51 <!--more-->
  52
  53 #### How to use a container?
  54
  55 The more containment and separation between applications, the more secure a system gets.
  56
  57 Unfortunately few applications come with ready-to-use definition of what access and other applications it requires to function at a minimum. There are ways of finding this out (makejail, documentation, strace, apparmor profiles), but it will always involve some work.
  58
  59 You have to find your own balance between the security one requires and the effort needed to attain it.
  60
  61 Furthermore, what even is an application? Is it a single program or daemon? Or a bunch of programs running in parallel and working in concert towards a single purpose?
  62
  63 #### How to NOT use a container?
  64
  65 Sometimes (web)developers see the Linux systems that run their (web)applications as a house of card that they better not touch or they don&#8217;t want to deal with security and quality policies of various Linux distributions. The reason being, that if it works for them, it should work just like that for the end-user. Conveniently containers now allow us to package an applications plus the whole linux ecosystem around it. Unfortunately this just makes everything worse. It makes it harder to actually secure and separate applications from each other while providing a false semblance of security.
  66
  67 ### What is chroot and what can and can&#8217;t it do?
  68
  69 A chroot is a root file system (e.g. a whole Linux distribution) inside your host root file system in which a program runs.
  70
  71 The idea being that a chrooted application can not access any file outside it&#8217;s chroot.
  72
  73 Obviously then you have to provide (duplicate) all the tools and applications that will be needed inside the chroot filesystem.
  74
  75 Tools like debootstrap help installing a debian linux inside a directory or image.
  76
  77 Chroot does not restrict assess to the network, syscalls, hardware devices like usb etc.
  78
  79 E.g. The root user inside a chroot can easly read harddisk device or re-mount it inside the chroot and do whatever he/she pleases.
  80
  81 ### Links to some great introduction to cgroups I came across
  82
  83 The RedHat-blog has some very good hands-on introduction articles on cgroups called &#8220;World domination with Cgroups&#8221; I suggest you read them:
  84
  85   * <p class="hero1-title">
  86       <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-1-cgroup-basics">Part 1 &#8211; Cgroup basics</a>
  87     </p>
  88
  89   * <p class="hero1-title">
  90       <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-2-turning-knobs">Part 2 &#8211; Turning Knobs</a>
  91     </p>
  92
  93   * <p class="hero1-title">
  94       <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-3-thanks-memories">Part 3 &#8211; Thanks for the memories</a>
  95     </p>
  96
  97   * <p class="hero1-title">
  98       <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-4-all-ios">Part 4 &#8211; All the I/Os</a>
  99     </p>
 100
 101 &nbsp;
 102
 103 ### Restrict services using systemd unit files
 104
 105 Sometimes you just want to contain a single executable. In that case you might not truly need a full machine, you can chroot a service and restrict it just using it&#8217;s .service file.
 106
 107 My favorite: <tt>SystemCallFilter</tt>! it filters what syscalls a process is allowed to use.
 108
 109 e.g. you could run a program or bunch of programs with _strace -c &#8212; <cmd>_ and put the list of syscalls at the end in the systemd unit file.
 110
 111 Other extremely useful directives you should read up on:
 112
 113 <pre>ProtectHome=read-only || true\r
 114 ProtectKernelTunables=yes\r
 115 ProtectSystem=strict || full || true\r
 116 ProtectControlGroups=yes\r
 117 PrivateDevices=true\r
 118 #DevicePolicy=closed\r
 119 #DeviceAllow=/dev/urandom r\r
 120 #DeviceAllow=/dev/random r\r
 121 NoNewPrivileges=true\r
 122 ReadWritePaths=\r
 123 ReadOnlyPaths=\r
 124 InaccessiblePaths=\r
 125 PrivateNetwork=\r
 126 MountFlags=\r
 127 AmbientCapabilities=\r
 128 CapabilityBoundingSet=</pre>
 129
 130 &nbsp;
 131
 132 chroot:
 133
 134 <pre>RootDirectory=</pre>
 135
 136 ### What about containers as virtual machines replacement? Enter systemd-nspawn
 137
 138 systemd-nspawn is systemd&#8217;s tool to run containers like you would a virtual machine. Thus &#8216;nspawn containers are called &#8220;machines&#8221; and are managed with the tool <tt>machinectl</tt>. Actually machinectl interfaces not only with systemd-nspawn but also rkt, docker, libvirt and others, thus providing a convenient place to manage all your running virtualisations at once.
 139
 140 ### Putting our application into an container.
 141
 142 Easy! Create a chroot under <tt>/var/lib/machines/examplecontainer/</tt> and a permission/network/container configuration-file <tt>/etc/systemd/nspawn/examplecontainer.nspawn</tt>. Then boot it using <tt>machinectl start examplecontainer</tt>. Done.
 143
 144 #### Example examplecontainer.nspawn
 145
 146 <pre>[Exec]\r
 147 Boot=yes\r
 148 PrivateUsers=no\r
 149 \r
 150 [Network]\r
 151 ## put container (together with other containers)\r
 152 ## in a virtual private network-bridge called "examplevlan"\r
 153 Zone=examplevlan\r
 154 </pre>