LXC & SystemD Security Considerations
- matt.casperson
- michael.stuber
Note: The current design direction is to leave the container implementation details to the platform provider provided that it is interoperable with the container image approach.
Table of Contents
- 1 May 6th, 2025 Items
- 1.1 systemd vs. lxc
- 1.1.1 Integration and Scope
- 1.1.2 Configuration and Management
- 1.1.3 Isolation Implementation
- 1.1.4 Major Considerations
- 1.1.4.1 Container Escape
- 1.1.4.2 Adoptability
- 1.1.5 Net Takeaway
- 1.2 zeromq vs. dbus
- 1.1 systemd vs. lxc
May 6th, 2025 Items
systemd vs. lxc
Integration and Scope
Approach | Capability | Description |
systemd | systemd-nspawn (via systemd-machined) | Systemd-nspawn is a tool that is part of the systemd project, and integrates with systemd on the host via systemd-machined, which is a virtual machine and container registration manager. They can also be foreground or background processes if you use nspawn leveraging a .service unit. Further, if properly defined can be discoverable via machinectl. |
lxc | lxc-start, attach, etc. |
|
Configuration and Management
Approach | Capability | Description |
systemd | systemd-nspawn | Does not require special metadata to boot containers, i.e. you can wild west/yolo it to a degree. |
lxc | lxc-start, attach, etc. | Each container needs it’s own config file and root FS so there needs to be some forethought above and beyond systemd-nspawn prior to launching a container. |
Isolation Implementation
Approach | Capability | Description |
systemd | systemd-nspawn | Can leverage an unprivileged user if specified. This is in addition to the common features of cgroups, capabilities, seccomp, apparmor, MAC, etc. |
lxc | lxc-start, attach, etc. | Maps the root user in the container to an unprivileged user on the host using the user namespace, assuming no funny business with that namespace. This is in addition to the common features of cgroups, capabilities, seccomp, apparmor, MAC, etc. |
Major Considerations
Container Escape
Both lxc and systemd-nspawn rely on the same underlying kernel features for isolation and resource management. That said the biggest consideration here is operator familiarity with each technology and their ability to continually enforce security hardening for any particular approach. I.e. are folks going to be more comfortable with a systemd approach vs. lxc. The mechanisms to create sufficient isolate exist in both, however, it is unclear as to whether the implementer skillsets favor one over the other.
Adoptability
To progress this decision I think we should embrace the RFC process and engage stakeholders to get a read on their familiarity, technical expertise, lessons learned, any other feedback, etc. for these two approaches. I.e. typical RFC things.
Net Takeaway
In terms of, “what is possible”, there aren’t any material differences between the two to give one an advantage over the other. The overhead associated with implementing and operating the two are different, however, where one could argue that lxc provides a secure(er)-by-default approach whereas systemd does not as it relies on intentional configuration by the implementer. That isn’t to say the lxc secure(er)-by-default isn’t possible with systemd just that it requires some awareness and intention to achieve the lxc equivalents that you get by default.
zeromq vs. dbus
See https://lf-energy.atlassian.net/wiki/spaces/GEISA/pages/289931338