Re: [Discuss] Debian 12 in the Cloud
On Tue, 4 Jun 2024 02:04:16 -0400 Steve Litt wrote: > >You said there is a correlation even if it's not 1:1. > > > >I said that no such correlation exists. It's a myth. > > I'll need to see the URL to the statistical survey showing that in > order to accept it. I accept, and completely agree, that smaller, simpler code *can be* everything you say: easier to understand, easier to test, etc. It's a good programming philosophy to have. The myth is that size of attack surface *is* directly correlated with line count. This myth assumes that every line of every program is of consistent quality, and that every line of every program has the same exposure to attack. On the one hand, I don't know of any statistical surveys which demonstrate that neither assumption is true in the real world. On the other, do we really need such a thing in order prove that Daniel J. Bernstein writes better, safer code than Lennart Poettering? > The preceding timeline sounds reasonable and I believe it. However, it > doesn't contradict my point that systemd has too many dependencies for > them to handle, and distros deploying systemd can't do all the due > diligence to make sure it isn't a pathway to a supply chain attack. I have never denied the base assertion: systemd started life as a buggy mess, and has grown far too complicated with far too many dependencies to be reasonably managed. My disagreement is over the assertion that this badness is why the XZ supply chain attack happened. This simply is not true. The *form* of the attack was tailored to that specific dependency chain, but the reason why systemd and XZ were attacked and exploited is because they exist. If that dependency chain did not exist, if systemd were better designed, then the attack would have taken a different form, one tailored to that reality instead of ours. -- \m/ (--) \m/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
Can anyone recommend an overview document of systemd? A motivations/design kind of thing? Thanks, Dan ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
On Tue, 4 Jun 2024 09:54:32 -0400 Daniel M Gessel wrote: > Can anyone recommend an overview document of systemd? A > motivations/design kind of thing? Lennart Poettering's take: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/why.html -- \m/ (--) \m/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
> On the other, do we really need such a thing in order prove that > Daniel J. Bernstein writes better, safer code than Lennart Poettering? No, but we also don't need a double-blind study to show that the average programmer's approach to security is a lot closer to Poettering's than djb's. (I say this as a compliment to djb, not a dig at Poettering.) It seems obvious that there would be at least a weak correlation between LoC and attack surface, if only because the code that makes up the attack surface contributes to LoC. I'd need to see some substantial evidence to believe the claim that the coefficient is <= 0. > The *form* of > the attack was tailored to that specific dependency chain, but the > reason why systemd and XZ were attacked and exploited is because they > exist. If that dependency chain did not exist, if systemd were better > designed, then the attack would have taken a different form, one > tailored to that reality instead of ours. Okay, but that goes for all attacks. If the WebP vulnerability didn't exist, then people would have exploited iPhones using some other vulnerability instead. This is unrelated to the fact that the WebP vulnerability wouldn't have occurred if not for some bad choices made in libwebp. Similarly, patching sshd to add new runtime dependencies is a bad idea, and the people who did that should know better. It's true that the same social and technical techniques that were used to insert the XZ backdoor could hypothetically have been applied to a different runtime depency of sshd. This still doesn't absolve anyone of blame, or make it unreasonable to say that systemd played a part in making the XZ attack possible. If you want to qualify that statement with "in this reality," that's okay with me, but I think most people interpret most statements with that qualification implicit. -Ben ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
On 6/4/24 07:07, Rich Pieri wrote: Lennart Poettering's take: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/why.html Very interesting, thank you. Those point out to me that I should have more sympathy for systemd, they tackled a hard problem Unix's architecture has held up *really* well over the decades. At least the from the kernel's perspective. But what we expect of the user land part of the OS has changed a lot. The original init system was a simple framework for Unix programs to get themselves run at boot. But over time user land programs established ad hoc dependencies on each other, building up into an incomplete mess. Upstart's perspective* was that the problem is bigger than the original model (true), and so: "Hey y'all, rewrite everything to use our new API!", and they would optimize what the init system did, plus mediate all of this new dynamic stuff. (Reasonable summary?) Except nothing was programmed to this new model, while the old model and the old chaos still mostly worked. * Note Upstart failed: the URL http://upstart.ubuntu.com seems dead. systemd's approach is to roll their sleeves and start making things work better, based on the reality of what was happening with this-bus and that-bus and whatnot. And if "progress" means patching OpenSSH, then let's patch OpenSSH! Then this episode comes along and clearly demonstrates (to me at least) that if being pragmatic means patching OpenSSH, then it was necessarily the wrong approach. There are annoying, pedantic, philosophical arguments for why the expedient patching of other packages is a mistake, and annoying, pedantic, philosophical arguments are sometimes correct. So what was right approach? I don't know. Well, maybe I know a little: 1. Other than embedded boxes, we no longer boot computers that often (and even with embedded, only some small footprint devices get booted much, and they won't be running systemd), therefore optimizing for boot time was a mistake. 2. We now have crazy amounts of RAM (at least until someone launches one of those never-designed, bloated, general purpose OSs we misleadingly call "web browsers"), therefore optimizing for RAM was a mistake, too. But trim those two out, and does the problem simplify much? I fear not. We still have all those behavioral dependencies as the computer's configuration dynamically changes, and to me that seems the hard part. -kb, the Kent who doesn't know what a good solution would have been. P.S. Once upon a time when I was working on getting an embedded machine to boot faster. One of my clever ideas: Have our monolithic program, the thing that did the embedded work of the box, *be* PID 1, at least at first, so it could start running as soon as possible, initializing itself, moving motors, etc., but then have it pretty much immediately fork in to two. The process that kept PID 1 exec-ed busy box's init white PID 2 continued on in parallel. That, plus optimizing kernel boot time, meant we started doing our real work with so little delay that the time for the hardware's power-on-reset was a major component. ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
On 6/4/24 09:59, Kent Borg wrote: -kb, the Kent who doesn't know what a good solution would have been. Maybe the right approach was to not touch the init system at all, and instead finish all that D-Bus work to rationalize dynamic dependencies. Would that work? And maybe that means submitting a few patches to various important packages to implement some key D-Bus-something-something calls. That way those other packages (such as OpenSSH) could vet any changes to their code. Donno. -kb ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
I've been watching this with interest. Back around 1980 I designed a Unix equivalent to SysV init at Raytheon data systems because system v was not available at the time. While systemd has its issues, using SysV init to schedule start up dependencies is difficult. Any it's slow because it is based on shell scripts. But, systemd does handle dependencies well and significantly speeds up the initialization process. I would prefer systemd to be less of an everything package, but having struggled with initd dependent issues in a complex environment made me appreciate systemd. -- Jerry Feldman Boston Linux and Unix http://www.blu.org On Tue, Jun 4, 2024, 1:18 PM Kent Borg wrote: > On 6/4/24 09:59, Kent Borg wrote: > > -kb, the Kent who doesn't know what a good solution would have been. > > Maybe the right approach was to not touch the init system at all, and > instead finish all that D-Bus work to rationalize dynamic dependencies. > Would that work? > > And maybe that means submitting a few patches to various important > packages to implement some key D-Bus-something-something calls. That way > those other packages (such as OpenSSH) could vet any changes to their code. > > Donno. > > -kb > > ___ > Discuss mailing list > Discuss@driftwood.blu.org > https://driftwood.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Debian 12 in the Cloud
On Tue, 4 Jun 2024 09:59:25 -0700 Kent Borg wrote: > On 6/4/24 07:07, Rich Pieri wrote: > > Lennart Poettering's take: > > http://0pointer.de/blog/projects/systemd.html > > http://0pointer.de/blog/projects/why.html > > Very interesting, thank you. Those point out to me that I should have > more sympathy for systemd, they tackled a hard problem And despite all of the problems systemd has? It largely succeeded. Which is why distribution maintainers *love* systemd to pieces. It solves those problems so that they don't have to do it themselves, and does so more or less consistently across different distributions. upstart didn't so much fail as Canonical decided to embrace systemd instead. And I don't blame them for that decision: much more cost effective letting Red Hat do all that heavy lifting. -- \m/ (--) \m/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
