Sebastian Wiesner

systemd

#systemd #rust

Systemd has this feature which lets you change the log level of a service on the fly. You can actually do this:

$ sudo systemctl service-log-level systemd-resolved.service debug
$ resolvectl query some-funky-domain.example.com
$ sudo systemctl service-log-level systemd-resolved.service info

to get a debug log of systemd-resolved trying to resolve a specific domain.

This is backed by dbus: If a service listens on dbus and has its bus name defined in its unit file then it can expose the log control interface on its bus connection to let systemctl change its log level and log target.

All of systemd's own services support this interface, but unfortunately it hasn't seen wide-spread adoption outside systemd yet. Which is kinda sad, because it's really a great feature for debugging.

I certainly plan to use it more, so I put up logcontrol.rs on crates.io.

Discuss...

#archlinux #systemd #secureboot #dracut #sbctl

Discuss...

Update: I no longer use dracut, and the corresponding part of this blog post no longer reflects my setup.

This article describes my Arch Linux setup which combines Secure Boot with custom keys, TPM2-based full disk encryption and systemd-homed into a fully encrypted and authenticated, yet convenient Linux system.

This setup draws inspiration from Authenticated Boot and Disk Encryption on Linux and Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248 by Lennart Poettering, and combines my previous posts on these topics.

Read more...

#dracut #luks #sbctl #archlinux #systemd #secureboot

Discuss...

Historically cryptsetup and LUKS only supported good old passwords; however recent systemd versions extend cryptsetup with additional key types such as FIDO tokens and TPM devices.

I like the idea of encrypting the rootfs with a TPM2 key; it allows booting without ugly LUKS password prompts but still it keeps data encrypted at rest, and when combined with secure boot also still protects the running system against unauthorized access.

Secure boot will prevent others from placing custom kernels on the unencrypted EFI system partition and booting these, or changing the kernel cmdline, in order to obtain root access to the unlocked rootfs. LUKS encryption with a TPM-based key bound to secure boot state protects the data if someone removes the hard disk and attempts to access it offline, or tries to disable secure boot in order to boot a custom kernel.

I’ve covered secure boot setup in a past article; this article talks about the TPM2-based encryption.

Read more...

#archlinux #systemd

LWN recently covered a comprehensive guide about discoverable GPT disk images by Lennart Poettering.

Read more...

#systemd #luks #dracut #archlinux

Discuss...

Installing Arch on a LUKS-encrypted dsik traditionally required a few careful configuration steps to configure the proper root device for booting; if any of these steps was omitted or done wrongly the system would fail to boot. With systemd and dracut however a LUKS-encrypted Arch system can boot safely and reliably without any configuration:

  • Dracut builds a unified EFI kernel image including microcode and a generic initrd with systemd and cryptsetup.
  • systemd-boot automatically discovers unified kernel images installed by dracut and automatically adds them to the boot menu without explicit boot loader configuration.
  • At boot systemd automatically discovers and mounts the root file system following its DISCOVERABLE PARTITIONS specification.

The following commands demonstrate a fresh Arch installation from the Arch installation media into a libvirt VM. Installing to a pristine physical machine or a different virtual machine provider should require only minimal changes; adapting an existing system may be more difficult and require more work.

Read more...

#archlinux #systemd #homed

Observations from using systemd-homed for a couple of days:

Read more...