The third LXD / LXC technology in this series is CGmanager, which is the final undergirding technology, the one that enables secure cgroup (control group) management for Linux containers. CGmanager is necessary so that Canonical can provide LXD with LXC. “It’s part of the nuts and bolts, the nitty-gritty underneath LXD,” says Dustin Kirkland, Strategist, Container Offerings, Canonical.
CGmanager is a daemon enabling an unprivileged user to create, start, and use unprivileged containers in a secure manner. CGmanager not only enables non-root users to form containers but also to add more containers inside of that first container. This helps to natively support the nesting of containers. CGmanager works with only one CGmanager daemon per host system.
CGmanager: Not Like the Rest
When speaking of some other examples of container technologies, users will note that there are containers that must wrap the launch of the container with SUDO, a program that runs programs with the same security privileges as the superuser. Otherwise the technology must launch containers as root. “But with LXD, any user, any non-root user that you give permission to by adding them to the LXD group can then create containers, and it’s all managed by user namespaces and cgroups,” says Kirkland.
“CGmanager allows you to run LXD inside multi-tenant environments, ensuring that a malicious user inside of a container that manages to somehow exploit that container and escape that container is no more than an unprivileged user,” says Kirkland. The only feasible means for escaping a container is by using a zero-day attack on an unpatched vulnerability. There are currently no such vulnerabilities that are known that are unpatched or unchecked.
So the root user can do all sorts of damage inside its own container. “It can blow away the file system for example. But it’s still confined to being within that container,” says Kirkland.
The potential risk in a cloud environment such as Amazon, Google, Azure, or OpenStack is that a malicious party with root access and control inside of an instance who also has a zero-day exploit for an unpatched hypervisor vulnerability could manage to escape the hypervisor.
What cgroups and CGmanager together provide is the assurance that when that container is launched, it is not launched as root on the host operating system. “It is launched as a non-root user, such that, if the user does escape that container, they are no more than that unprivileged, non-root user on the host,” says Kirkland.
At that point in order to be any threat the user would have to have a root exploit for the host. “So with that we’ve created this incredibly difficult set of requirements that would be necessary for an attacker to fulfill before they could actually do any damage to the host system, or to any other peer container on that system,” says Kirkland.
“Together with LXCFS and LXD, CGmanager is a technology that is part of Linux containers, and it’s all part of what enables LXD to run. So, CGmanager is already a fundamental technology that we’re using as part of our dependency chain, it’s part of our building blocks, the foundation on which LXD is built,” says Kirkland.
CG manager simplifies the cgroup management of the code in LXC and LXD. “So, LXC and LXD call out to CGmanager to help with the cgroup management, so it provides a general abstraction layer. Cgroups are, perhaps, useful outside of LXD, alone, so CGmanager provides that abstraction level, and then Linux containers simply use the CGmanager to simplify its callouts to cgroups,” explains Kirkland.
According to data from Canonical, CGmanager simplifies cgroups through multiple mounting options located intuitively in the directory structure such as in /sys/fs/cgroup/subsys where users will find code for the full mount of cgroups, the bind mount of cgroups, no mount, and a fake path leading to the container cgroup. Cgroups can also be all co-mounted, all mounted separately, or a mix of co-mounted and not co-mounted, according to data from Canonical.