Lennart Poettering / is on Nostr

⛵ I write software. ⛵

Web: http://0pointer.de/blog/

Last Notes

2024-08-27 08:02:27

- reply

…you really have to.
(I am trying to do my part on this of course, i.e. in systemd we measure a lot of things during boot now, and our FDE logic is hooked up with it.)
[That all said, I think SB might have some value if you enroll your own keys, which however can only work on very specific hw, and in VMs, but is probably not a solution realistic for general purpose PCs]

2024-08-27 08:00:23

- reply

…it is is "democratic", in the sense that anyone can do this without having to get their keys into some centralized keyring.
Hence, to me it implications of SB are simply not worth it, it brings very little to the table security wise, but creates massive headaches on deployment. MB otoh actually provides a high level of security, and you don't have to ask anyone to put together your own policies.
Hence if you ask me: focus on making MB a thing on Linux, and bother with SB only to the level…

2024-08-27 07:57:09

- reply

Much more interesting is Measured Boot when tying disk encryption to it. Various OSes, including Windows have been supporting this since about forever. And it's so much better: it basically makes no restrictions on what you can run on your PC. All it enforces is: my encrypted disk can only be decrypted if the OS of my choice is booted in the version of my choice. And that's a *way* more powerful concept, because it is *focussed* on your installation, because…

2024-08-27 07:53:46

Noone asked me, but if you are curious what my take on the recent sbat/SecureBoot kerfuffle is, I'll let you know anyway:
Frankly, I find SecureBoot ultimately pretty uninteresting tech. It casts a very wide net: it basically is a politically charged global allowlist, yet is useful as a very very lose denylist only, because it necessarily contains so so so much stuff. I think the value for security is relatively limited, because it it attempts to be universal, and hence can never be focussed.

2024-04-30 08:25:55

6️⃣ Here's the 6th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
In the 2nd installment of this series we have already discussed system and service credentials in systemd a bit. Quick recap: these are smallish blobs of data that can be passed into a service in a secure way, to parameterize, configure it, and in particular to pass secrets to it (passwords, PINs, private keys, …).

2024-04-29 07:42:01

- reply

… enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.
So, in my ideal world, we'd have an OS entirely without SUID. Let's throw out the concept of SUID on the dump of UNIX' bad ideas. An execution context for privileged code that is half under the control of unprivileged code and that needs careful, …

2024-04-29 07:39:51

- reply

… worse, but are not in themselves the main issue with sudo.
SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended for and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice…

2024-04-29 07:34:42

- reply

This has led various people to revisit the problem and come up with alternatives: most prominently there's probably OpenBSD's sudo replacement called "doas". While it greatly simplifies the tool and removes much of the attack surface, it doesn't change one key thing: it's still a SUID binary.
I personally think that the biggest problem with sudo is the fact it's a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem…

2024-04-29 07:32:14

- reply

… allows users to operate at minimum privilege: do most of their work without privileges but temporarily acquire them where needed, all without leaving the shell workflow, integratable with shell scripts, pipelines and so on.
sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.

2024-04-29 07:27:59

5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.
"sudo" is very very useful, as it…

2024-04-03 09:43:45

- reply

…
Nach reiflicher Überlegung und angesichts der sowieso überbordenden
Komplexität der ganzen US Software Stacks gilt nun wieder: "Back to the
roots!"
https://smarden.org/runit/ für deutsche Clouds, Desktops
…
Viel Glück bei den Amis!
---
Or in other words: 🇧🇪 🇧🇪 🇧🇪 RUNIT FÜR DOITSCHE CLOUDS1!!1! 🇧🇪 🇧🇪 🇧🇪

2024-04-03 09:42:23

As you might guess I get a certain amount of "fan" mail regularly. It's usually pretty dumb and not worth to mention. But sometimes it's so funny, that I just have to share the good parts of it. So here some comments from a recent mail I got (sorry, in German):
Subject: Tja, schade! War definitiv die falsche Entscheidung zu Microsoft zu wechseln
Hi Lennart!
Das war schon eine ziemliche Überraschung für uns alle!!!
…

2024-04-03 08:07:17

Credit where credit is due! I'd really like to take a minute and thank Jia Tan how they helped us to finally get sd_notify() support merged into OpenSSH upstream!
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
Thank you, Jia, you rock!