A collection of NixOS configurations for all my machines, built on zero-trust and compartmentalisation, and kept minimal: the host carries only what it uses and declines the defaults it does not need. The host carries no work of its own: everything I do lives in realms, each kept apart from the others.
I wear several hats, with segregation of duties between them. Each role needs an environment of its own, and one role must not be able to act as another. I would rather keep a single system up to date than carry several outdated.
Each realm behaves as a separate system, and only the context I am working in is unlocked at any given time. Actions that matter are approved with distinct hardware security tokens. On top of that sit separation of duties and compartmentalisation.
I write web, Linux and Android applications, dig into low-level Linux stuff (usually network-related), work on embedded systems, and play with amateur radio from satellite using SDRs to VHF/UHF stuff.
The host is an access mechanism. It holds no work and no data; it only lets me reach realms.
The host is ephemeral. Its root filesystem is recreated on every boot, so nothing accumulates on it that the configuration does not declare.
The host is, at least in principle, not tied to a device. A configuration describes a kind of machine, and nothing in the system image says which unit it is running on.
A machine's identity lives on a separate volume, not in the image, and reaches the system through Orma. The image carries a schema of the identity it expects; during early boot, Orma checks the identity volume against that schema. The identity is not sealed to a TPM or a security key, so it can move to new hardware, or be recovered, without the chip or token it was first used with.
A realm is an encrypted volume holding data, config and the identity of one activity. It is unlocked when I enter it and locked again when I leave.
While open, a realm runs as its own user and in its own sandbox. What happens in one is not visible to the others.
Each realm has its own lifecycle. Its software is a derivation of its own, activated from inside the realm, and is not part of the system closure. A small change in a realm does not rebuild the host, and a realm does not pull the host's configuration in with it.
Most of the time everything is upgraded together anyway. The split is there for when a realm has to stay behind, or move ahead of the rest for reasons.
Each realm reaches the compositor through a Wayland socket of its own, labelled as a security context with way-secure. The compositor withholds from it what it withholds from any sandbox: reading the clipboard or other windows in the background, capturing the screen, injecting input, and drawing panels or overlays.
Ordinary windows, copy and paste and drag and drop keep working. Prompts, such as the PIN entry for a security token, open as regular windows.
X11 applications run against an Xwayland of the realm's own (xwayland-satellite), never the host's X server.
Devices are not directly accessible from inside a realm. Whatever their file permissions say, a realm can only open an allowlist: the GPU's render node, security tokens and hardware wallets, and USB-serial boards.
Applications that expect a device directly are therefore wrapped. One that
wants a camera at /dev/video* is run through PipeWire's V4L2 compatibility
layer instead.
Audio and cameras come from the host's system-wide PipeWire. A realm allowed to use it currently has unrestricted access to it, the microphone, the camera and other realms' streams included; restricting that per realm is still to be done.
Realms are separated by their users, by encryption at rest, and by the hardware tokens that approve what matters. They still share the compositor, restricted as described above, audio, and the network. The host is trusted by all of them.
nix run .#vmThe virtual machine runs from disposable disks. When asked for a disk password,
it is disko. Its login password is vm. Its realm volumes have an empty
passphrase. Inside, enter a realm:
bifrost enter midgardThe first time, this creates the realm's identity and asks for its password, then unlocks and mounts the realm's volume and opens a sandboxed shell in it. There is no graphical session in the virtual machine, so the realm is entered without Wayland.
From inside the realm, activate its environment from the checkout shared with the virtual machine (this needs network access):
nix run /mnt/metempsychosis#homeConfigurations.midgard.activationPackageLeave the shell and the realm closes: its volume is unmounted and locked again, and nothing of it remains on the host after a reboot.
I follow the XDG Base Directory Specification, mapped onto a
filesystem-hierarchy-like tree under ~/.local. The exact locations are set in
home-modules/xdg.
Before this configuration replaced it, the repository held a different one, evaluated for a whole fleet: a laptop, three servers and an ARM cloud instance deployed with Terraform. Each machine was built against a distribution, a pinned set of nixpkgs, home-manager and sops-nix; servers followed stable releases and the laptop followed unstable. A single harness evaluated every system with the same modules, secrets and flake registry.
Its most distinctive part was a module system joining NixOS and home-manager. Users belonged to profiles (reduced, simple and graphical, each implying the previous one), and a NixOS module could contribute home-manager configuration to every member of a profile, so one module configured the system and its users together. It also held NixOS containers for self-hosted services, secrets per host and per role, btrfs subvolumes rotated at boot (an early form of the ephemeral root here), and home-manager extensions for runtime actions and files regenerated by systemd units.
This repository is free software under the GNU General Public License, either version 3 or, at your option, any later version.