Lennart Poettering, creator of systemd, writes on init systems, socket activation, file locking and Linux boot security.
Commenters point to it as the best introduction to systemd's design, citing Rethinking PID 1 and the boot security post, though some question socket activation's value.
I find your comment here sadly indicative of the level of discussion around systemd from its haters.
Your metric is utterly misleading not only because you're almost certainly counting non-code files, but more crucially, because the systemd repository contains the code for *sixty-nine* entirely separate binaries, separate tools under the overall systemd project umbrella, so counting their collective code size as if it is the code base of one single gigantic tool, a single gigantic program that compiles into a single gigantic binary, with all the interweaving that implies, is just disingenuous at best. That number does not represent the size of a single attack surface area, and pretending it does is nonsensical. It's like pulling in the source of all of gnu and doing a line count. And for the record, I've actually done this properly, cloning the systemd repository and then reading the documentation to figure out what directories and source files did what, and assembled a list of the directories and source files that represented just systemd-the-init-system, and got about 240,000 lines of code.
And remember, it won't actually be systemd the init system that will be replacing sudo, it will be systemd-run, which is a separate binary, with a separate memory space, and a separate permissions model, that merely communicates with systemd the init system to get certain things done. I guarantee you it's probably smaller than the code base of sudo, and this architecture, as LP points…
This is an amazing release. As far as controversy clickbait topics go, personally I'm much sadder to see umerged-usr bite the dust, even though i'm a huge fan of merged-usr, just because it was super nice being able to boot off whatever / you have and drop another systems' /usr in. But at least there's systemd-sysext to allow some combining overlays. Anyhow, excited to talk through various changes that look exceptionally neat to me:
RootEphemeral=, which lets processes run in a filesystem snapshot; super neat for seeing what changes a process might make to your system. https://github.com/binpash/try was a popular submission a couple days ago, & this builds in a similar capability to the os.
RestartSteps= and RestartMaxDelaySec= to finally finally offer some level of control over exponential-backoff in the restart behavior.
FileDescriptorStorePreserve= is kind of mysterious, lets systemd store open file descriptors for a process even after it terminates. Some interaction with systemd-analyze. Not sure what this is for exactly but definitely cool extra visibility/observability of processes. I tend to think it also potentially could be useful allow for some weird/fun stuff like restarting services without closing ports.
Soft-reboot which can be useful for switching roots without having to juggle bootloading. Very useful for anyone doing partitioning or what-not. And as I hinted above, you can pass file-descriptors, meaning you can avoid service-interruption while rebooting;…
Good recommendations. OSes today are more than kernels. Filesystems, init systems, shells, and the configuration conventions would all be part of it. And probably also the windowing system and desktop environment.
The most innovative concepts historically would be Plan9, BeOS, and seL4.
Plan9's approach of "everything is a file" is something that was unique.
BeOS's extensive use of journalling and metadata in the filesystem gave it big advantages.
seL4 being the most rigorous application of a micro-kernel architecture, and making use of formal verification make this one stand out.
Capability-based operating systems also offer immense benefits.
Fuchsia and Redox are clearly drawing some inspiration from these. Along with GNU Hurd, which you didn't mention.
As for shells, nushell is clearly revolutionary. Something that points to what a better world might have been.
I would also recommend looking at Lennart Poettering's vision that extends on innovations like cgroups, journalling filesystems, ostree, etc.
https://0pointer.net/blog/projects/stateless.html
And of course, Nix and Guix both align with this vision of reproducibility, statelessness, and transactionality... along with Fedora Silverblue.
I kinda think of this as making the filesystem work more like git. A distro is a branch. A rollback is a branch from a previous commit.
And then the build system would be completely idempotent... every compilation from any system would be byte-for-byte identical, and thus…
One of the incredible & fantastic superpowers of systemd. There so much isolation it can give you, rescind so many powers!
Alas this article doesn't include even the most rudimentary of examples.
Let's look at recent gnome gdm session picker changes. They now use dynamic users, rather than statically allocated ones, helping make sure the picker never gets access to things it shouldn't have (since there's no static user id that an attacker might grant access to). A nice feature from systemd in 2017. So easy to add! DynamicUser=yes and you're good! https://0pointer.net/blog/dynamic-users-with-systemd.html
This also gives you a bunch of other security options by default.
PrviateTmp=yes. ProtectHome=readonly. ProtectSystem=strict.
This is just the tiniest cut of what systemd can do to make your system more secure, how it can help you make use of the kernel to limit your process. There's so so many ways to limit programs. Limit maximum tasks, set Nice= CPUWeight=, IOWeight=, limit CapabilityBoundingSet=, TasksMax=, limit network interfaces, tie a program to certain nftables, just so many. This huge page is but a start: https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html !!
Systemd makes excellent excellent use of the kernels namespacing feature to radically boost isolation of programs, to reduce their ability to impact the world in unexpected ways. Even better, you can manage multiple competing realms of apps very very effectively with a…
The article title is very misleading. This isn't bypassing FDE in any way. It's just getting a root shell on a machine you have physical access to with a particular boot configuration.
Clever? Yes. But no encryption is bypassed.
Most systems will only be listening to PCR 7 anyway, so a similar attack could be done by loading your own custom bootloader, or possibly reading messages on the SPI bus when booting. This is just a nice trick that's easier/faster.
There is a balance of convenience versus security and this could be prevented easily by disabling recovery shell or registering more PCRS (with correct boot setup), but would be much more annoying to remotely administer since you could get failure states where the TPM won't release the keys in a variety of situations.
Ultimately TPM-only unlock is a significant increase in security vs unsophisticated attackers and probably fine for 99% of people, but isn't something to rely on if you are concerned about sophisticated attackers.
Even with perfect PCR setup and enrolling only custom keys in UEFI, a running machine is still vulnerable. Cold boot or DMA attacks (Thunderbolt or PCI) are just a few that come to mind. These sound extremely sophisticated but are easily done even with hobbyist equipment. Any running machine with currently unlocked disks should be assumed to be possible to compromise with physical access.
If interested in Linux boot chain Poettering has a good read:…
> What about /boot - encrypted and tamper proof? Resists evil maid attack?
> Rabbit hole, I know, but so fascinating if you solved it all :)
Encrypting `/boot/` is the wrong thing to do. One can just replace it with something that logs the encryption key instead (and sends it off to somewhere). You actually need to verify that what you expect to be there is actually there and a encryption isn't gonna do that for you.
A reasonably secure boot chain looks roughly as follows: bootloader is checked by the UEFI (read secure-boot), bootloader chain loads a signed UKI which also uses secure boot verification (or just skip the bootloader if you only have a single kernel with no fallback), this then loads a signed dm-verity `/usr/` which brings you to the login screen. Root is just data (e.g. mounted `noexec`) and is encrypted using e.g. PCR 11 so that it only unlocks if the UKI is the one that is expected (with some other backup unlock method).
This is basically #2 of the "Design Goals" of Poetterings "Fitting everything together"[0]. It's a good read if you are looking to designing your own Linux image and are looking for some inspiration. There is ParticleOS[1] which somewhat dogfoods this kind of system, though I don't think it is anything remotely considered for a production system.
[0]: https://0pointer.net/blog/fitting-everything-together.html
[1]: https://github.com/systemd/particleos