Immutable, Fully-Confined Debian Server Images, Even on a Raspberry Pi 3
Using mkosi and apparmor.d as building blocks, this talk presents a prototype minimal Debian server. The goal is not to provide yet another Linux distribution, but to explore how hard it is to build personalized, hardened server images.
On top of the usual mkosi-backed features such as UKIs, A/B updates and dm-verity, the project adds a whole-system AppArmor policy and an immutable `/etc`. Because older devices also matter, the prototype supports the Raspberry Pi 3 (UEFI) too, with minor changes to the security model. The talk presents the differences in design, attacker model, and implementation between the various targets.
This talk walks through a prototype: a minimal, hardened Debian server built with `mkosi` and `apparmor.d`. It composes three layers of systemd and Debian tooling that are well understood alone but rarely combined, each reinforcing the others:
- **Image-based OS:** `mkosi` magic.
- **Whole-system MAC:** AppArmor policies that confine every process on the system. It also brings:
- Multi-layered policy loading, fixing the AppArmor load-time issues that hurt small devices.
- Immutable security policies.
- Compatibility with systemd sysext/confext.
- **Immutable `/etc`:** assembled from signed `systemd-confext` images, closing immutability's usual escape hatch.
The same image targets both an x86-64 server and a Raspberry Pi 3 (UEFI), and that contrast is where it gets interesting. The two share a single build but diverge on attacker model and security guarantees: what an embedded device with no Secure Boot can promise versus a server, and where the implementation has to bend. We walk those differences, the limitations, and what would have to land upstream to make this kind of image easier.
Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/