tag: #systemd

sudo's oldest weakness is structural - it is a large setuid program that starts as root holding a process the untrusted user built. run0, from systemd 256, escalates the opposite way, by asking the already-privileged systemd to spawn a clean process with no inherited context and no setuid anywhere. Here is the real architectural difference, when it matters, and why sudo still wins for automation.

Every service on your box runs with far more power than it needs. systemd has a full sandboxing toolkit built into the service manager that strips a service down to what it actually requires, no extra software, just directives in the unit. Almost nobody uses it. Run systemd-analyze security once and you will see why that is a problem.

GRUB has been the default Linux bootloader for two decades. For most of those decades it was the right default. On a modern UEFI system that runs exactly one operating system, it is not. The smaller, simpler, UEFI-native alternative has been mature for years and should be the choice that an engineer makes deliberately rather than the default that lands on the disk because nothing pushed back.

the basiscs around systemd