https://training-course-material.com/index.php?action=history&feed=atom&title=Not_Only_DockerNot Only Docker - Revision history2026-04-21T09:04:09ZRevision history for this page on the wikiMediaWiki 1.45.1https://training-course-material.com/index.php?title=Not_Only_Docker&diff=53832&oldid=prevApatrakov: /* Now you understand bocker! ⌘ */2017-04-15T16:21:20Z<p><span class="autocomment">Now you understand bocker! ⌘</span></p>
<p><b>New page</b></p><div>[[Category:private]]<br />
<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" ><br />
;title: Linux Containers: Not Only Docker<br />
;author: Alexander Patrakov<br />
</slideshow><br />
<br />
== Virtualization ⌘==<br />
<br />
* Run another OS (including another copy of the kernel) in a virtual machine<br />
** OK to run Windows VM on Linux<br />
* Good level of security & isolation<br />
** Separate virtual disks, network stack<br />
** Hacked VM != hacked host<br />
** Can run any OS<br />
* A lot of performance overhead related to emulation of virtual hardware<br />
** Somewhat solved by paravirtualization<br />
** Virtual machines eat memory for caches - partially solved by ballooning<br />
<br />
== Containerization ⌘==<br />
<br />
* Running another tree of processes under the same kernel<br />
** They don't see other processes<br />
** They have their own view of the filesystem<br />
** They have their own copy of the network stack<br />
** They look and feel like a virtual machine in some sense<br />
* No overhead<br />
** Native performance of e.g. disks<br />
** Only as much memory occupied as when running directly on the host<br />
* Somewhat less secure than a virtual machine<br />
** But still good enough for many use cases<br />
* Good only for runnng Linux software<br />
<br />
== Why people use containers and VMs ⌘==<br />
<br />
* Reproducible deployment of services<br />
** Just copy a VM or container image onto a host, and start it<br />
** No need to configure the application inside<br />
** No need to worry about compatibility with the host<br />
* Multi-tenant setups<br />
** Isolation and security matter here<br />
<br />
== Popular container runtimes ⌘==<br />
<br />
* <big>'''Docker'''</big><br />
** Many people don't know that alternatives even exist!<br />
* Everything else server-side<br />
** LXC/LXD<br />
** systemd-nspawn<br />
** runc<br />
** Rocket<br />
* On the desktop<br />
** Flatpak<br />
** Snap<br />
<br />
== Container building blocks ⌘==<br />
<br />
* Namespaces<br />
** man 7 namespaces<br />
** UTS, PID, User, Mount, Network, IPC, Cgroup<br />
* Cgroups<br />
* Management software<br />
<br />
== Chroot ⌘==<br />
<br />
* A mechanism that allows to change the view of the filesystem<br />
** Some existing directory is treated as root directory for a process<br />
** Chroots are entered using a chroot() system call<br />
*** Not bulletproof - root can escape<br />
*** No other security - processes in a chroot can send signals and use network as usual<br />
<br />
== Let's create a chroot ⌘==<br />
<br />
* Chroot with Debian or Ubuntu:<br />
** Use [https://wiki.debian.org/Debootstrap debootstrap], it is packaged for many distributions<br />
** debootstrap jessie /tmp/jessie<br />
* Chroot with Fedora/CentOS/OpenSUSE:<br />
** Use [https://collab-maint.alioth.debian.org/rinse/ rinse], it is packaged for Debian and Ubuntu<br />
*** On other distributions install from source<br />
*** If you are on CentOS/Fedora and want to create a chroot of the same kind, you can use supermin instead<br />
** rinse --arch amd64 --directory /tmp/centos --distribution centos-7<br />
<br />
== Entering a chroot ⌘==<br />
<br />
mount -t proc proc /tmp/jessie/proc<br />
mount -t sysfs sysfs /tmp/jessie/sys<br />
chroot /tmp/jessie<br />
. /etc/profile # to set the correct $PATH<br />
ls # runs in a chroot<br />
exit<br />
<br />
== Some thoughts about chroots ⌘==<br />
<br />
* Chroot is a privileged operation<br />
** Can you think why?<br />
* Chroot can be escaped from by root<br />
** Let's say "escaped" means "/etc/hacked" created outside of the chroot<br />
** Can you think of a few ways?<br />
*** [https://filippo.io/escaping-a-chroot-jail-slash-1/ The "textbook" answer] is relying on chroot('..') but there are other ways to do it<br />
<br />
== Trying Out Namespaces ⌘==<br />
<br />
* C programmers use these system calls:<br />
** To create a new namespace for the current process: unshare<br />
** To create a new process in a new namespace: clone<br />
** To enter an existing namespace: setns<br />
* Shell utilities:<br />
** unshare: creates new namespaces, runs a shell (or anything else) there<br />
** nsenter: enters existing namespaces<br />
<br />
== Some examples ⌘==<br />
<br />
* Bad example: PID namespace created but /proc still refers to the old one<br />
<br />
# unshare --fork -p /bin/bash<br />
# echo $$<br />
1<br />
# pstree<br />
... lots of processes ...<br />
# exit<br />
<br />
* Proper way to create PID namespace<br />
** Combine it with a mount namespace<br />
** Mount a private copy of /proc<br />
<br />
# unshare --fork -p -m --mount-proc /bin/bash<br />
# pstree<br />
bash───pstree<br />
# exit<br />
<br />
== Exercise ⌘==<br />
<br />
* Create PID and mount namespaces for a new bash process<br />
* Verify by mounting a tmpfs on /mnt that the mount namespace works<br />
* Enter this namespace with nsenter<br />
<br />
== Network namespaces ⌘==<br />
<br />
* Separate set of interfaces, routing tables, iptables/ip6tables rules<br />
* How to create:<br />
# ip netns add <namespace_name><br />
* How to move an interface (cannot be undone):<br />
# ip link set <interface> netns <namespace_name><br />
* How to run commands:<br />
# ip netns exec <namespace_name> <command> <arguments...><br />
* Clean up:<br />
# ip netns del <namespace_name><br />
* [http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/ Helpful blog post]<br />
<br />
== Exercise ⌘==<br />
<br />
* Connect to a free OpenVPN server: https://www.vpnkeys.com/get-free-vpn-instantly/<br />
** Known issue: MTU must be limited<br />
** Don't allow openvpn to pull routes, as this may interfere with VNC<br />
** Set the DNS server to 8.8.8.8 on the host<br />
* Move the tun0 interface to a separate network namespace<br />
* Set up tun0 as the default route in that namespace<br />
* Run the other browser there, as your user<br />
** Verify that you are accessing the internet via the VPN from the namespace<br />
* Can you create a nested connection to the same VPN server?<br />
* Try to predict what happens if you stop the VPN<br />
<br />
== Cgroups ⌘==<br />
<br />
* Hierarchical organization of processes in a system<br />
** Used e.g. by systemd to track when a service terminates<br />
* Resource limiting via controllers<br />
** CPU, ram, block i/o, bandwidth, ...<br />
* Controlled via a special filesystem, cgroupfs<br />
* Documented e.g. in:<br />
** [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/index.html RedHat Linux Resource Management Guide]<br />
** man 7 cgroups<br />
<br />
== Cgroup security model ⌘==<br />
<br />
* To move a task to a different cgroup, write access to the target cgroup is required<br />
** This means: root can escape, i.e. evade resource limits<br />
<br />
== Controlling the cgroup hierarchy ⌘==<br />
<br />
* Direct way: you can modify files under /sys/fs/cgroup<br />
* Convenient shell wrappers: cgcreate, cgexec<br />
** Parts of cgroup-tools in Ubuntu, libcgroup-tools in CentOS<br />
** Use lscgroup to see the available cgroups<br />
<br />
== Now you understand bocker! ⌘==<br />
<br />
* [https://github.com/p8952/bocker Bocker] is a toy container engine<br />
** ~100 lines of bash code<br />
* Read the code, play with it<br />
** '''bocker pull''' doesn't work due to Docker registry API change, use '''bocker init''' instead<br />
** Debootstrap a directory, configure openssh-server there, create an image and a container from it<br />
** See if you can ssh there<br />
** Can you escape?</div>Apatrakov