arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

Rewrite again

Browse source
This commit is contained in:
Quentin 2021-07-14 23:40:14 +02:00
parent 5579c70d92
commit f43635d645
Signed by untrusted user: quentin
GPG key ID: A98E9B769E4FF428
1 changed files with 7 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
_posts/2021-07-14-lxc-drop-capsysadmin.md
View file

@ -11,16 +11,17 @@ tags:
- containers
---
Hardening Linux Containers, and more especially [LXC containers](https://linuxcontainers.org/fr/lxc/introduction/), is needed to prevent a malicious user to escape your container. However, even hardened, a container can't be considered totally safe today. You can consider this article as part of a [defence in depth strategy](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)). But before starting, we need to understand how containers work under the hood.
Hardening Linux Containers, and more especially [LXC containers](https://linuxcontainers.org/fr/lxc/introduction/), is needed to prevent a malicious user to escape your container. However, even hardened, a container can't be considered totally safe today, so don't rely solely on this article for your security! Instead, you should consider it as part of your [defense in depth strategy](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)).
As said by Jessie Frazelle in her blog post [Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs](https://blog.jessfraz.com/post/containers-zones-jails-vms/), containers in Linux are not a top level design like Zone in Solaris and Jails in BSD.
To understand how a container can be hardened, we must understand how they work under the hood.
Jessie Frazelle describes magnificently their concepts in her blog post [Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs](https://blog.jessfraz.com/post/containers-zones-jails-vms/).
The critical point is that containers in Linux are not a top level design like Zone in Solaris and Jails in BSD:
> A "container" is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers.
> A "container" is just a term people use to describe a combination of Linux [capabilities,] namespaces and cgroups. Linux [capabilities,] namespaces and cgroups ARE first class objects. NOT containers.
In this article, we will focus on one first class object, capabilities, in a specific context, an LXC container.
The challenge when it comes to hardening a LXC container, compared to other solutions, is that there is a great probability that you'll run systemd in your container. And systemd heavily uses the primitives quoted before. Especially, systemd relies on *cgroups* to handle its services. We can also mention that many systemd daemon will be provided with a configuration that need to interact with the *capabilities*.
In this article, we'll boot a container running systemd without `CAP_SYS_ADMIN`, all other hardenings being out of scope for now.
The challenge when it comes to hardening a LXC container, compared to other solutions, is that there is a great probability that you'll run systemd in your container. Because systemd is a powerful init system, it assumes it also requires many permissions: we will see here how to start here despite our capability hardening.
If you feel a bit lost with containers, a good start is the reading of this whitepaper by the NCCGroup: [Understanding and Hardening Linux Containers](https://www.nccgroup.trust/us/our-research/understanding-and-hardening-linux-containers/). This post is also inspired by the article written by Christian Seiler, [LXC containers without CAP\_SYS\_ADMIN under Debian Jessie](https://blog.iwakd.de/lxc-cap_sys_admin-jessie), but we'll see that, due to evolutions in the Linux kernel, the proposed configuration does not work anymore out of the box.