[Discuss] Debian 12 in the Cloud

[slitt at troubleshooters.com (Steve Litt)]

Rich Pieri said on Sun, 2 Jun 2024 10:42:10 -0400

>On Sat, 1 Jun 2024 23:03:37 -0400
>Steve Litt <slitt at troubleshooters.com> wrote:
>
>> Systemd has about 80 times more lines of code than runit. I know this
>> doesn't 1 to 1 correspond to attack surface, but it's a reasonable
>> approximation.  
>
>Numbers of lines of code does not correlate with attack surface.

That's exactly what I said, except I used the word correlate.

>Neither does code complexity. At the most absurd lower end, a program
>that sanitizes strings has more lines of code and is longer and more
>complex than a similar program which does not sanitize strings. I hope
>we all agree that the "longer and more complex" version is probably the
>more secure version.

If you mean your case of input sanitizing vs no input sanitizing,
you're correct.


>Smaller and simpler is easier for fewer people to understand and
>maintain. No argument there. But code quantity is not and has never
>been a measure of code quality. 

You can repeat the preceding mantra a thousand times, but it doesn't
make it true.  In general, all other things being equal, smaller and
simpler is easier to debug, easier to understand, easier to unit test
[1], and therefore easier to make error free and secure, *all other
things being equal*.

>I hold that systemd is bad not because
>it is big and complex, but because the much of the code is buggy
>rubbish, and I would hold this opinion if it were half the size of
>runit.

I'm glad we agree on this. The architecture of systemd is a ridiculous
ball of thick interface interdependencies [2]. If somebody managed to
produce something that horrible in 1000 lines of code, it would still
be horrible.

>And this is all entirely irrelevant to the XZ supply chain attack,
>because the backdoor isn't in the source code. It's in the test
>harness. If you used 'git clone' then you would never see it because
>the payload was excluded by the .gitignore file. You had to use the
>tarball, and you had to build under specific conditions, for the
>payload to be injected into the source at build time.

LOL, far be it from me to defend the likes of Redhat and Debian, the
people who packaged this security breach. In my opinion, they suck, and
I've had that opinion for a long time. But watch this chain of
causation:

* Long game evil SOB tortures overworked, underpaid XZ maintainer

* Maintainer puts evil test blob in the XZ source code [whoops]

* Systemd incorporates XZ into itself [reasonable]

* Systemd crew fails to security check all their dependencies [clowns]
  [3]

* XZ includes test **BLOB** in its distribution [bozos]

* Redhat and Debian compile test blob into systemd [incompetents]

* Redhat and Debian compile systemd components into sshd [idiots] [4]

* The world comes within 1 day of 90% of Linux computers becoming
  compromised. [whew]

* One Microsoft engineer, while troubleshooting, finds the flaw [thank
  you, thank you, thank you Andres Freund]

In summary, the fact that the exploit wasn't in systemd itself misses
the point. The point is that systemd's massive overcomplexificationism
includes gratuitous promiscuous dependencies and to insert those
dependencies into the daemon itself for the "systemd preferred method
of notification".

I doubt systemd's Rube Goldberg machine could have been written in a
mere 15K lines of code in a way that couldn't easily be removed, which
is the reason for my assertion that all other things being equal, more
lines of code correlate with more bugs, exploitable and otherwise.


And now for the numbered references within this email:

[1] Thinner interfaces and one-input, one-output interfaces make unit
    testing much easier, and easier unit testing tends toward more
    security, all other things being equal.

[2] http://www.troubleshooters.com/linux/systemd/lol_systemd.htm

[3] The more external dependencies you have, the more difficult it is
    to quality or security check them all. The more difficult it is to
    security check, the more likely a problem will slip through.

[4] Yes, I understand that Debian and Redhat felt compelled to compile
    in the systemd library because systemd's preferred method of daemon
    notification is the systemd proprietary type=notify, type=reload,
    or type=dbus. This is my point exactly. For optimal systemd
    performance, systemd requires the daemons it manages to have
    the systemd library and its tens or hundreds of dependencies
    compiled into the daemon, even if the daemon requires the utmost of
    security. What could *possibly* go wrong? Note that the s6
    notification system requires about 10 lines of code in the daemon
    (write and receive a newline to a specific file (a fifo if I
    remember correctly, but been a long time). Contrastingly, systemd
    must bring in tens or hundreds of dependencies. Supply chain
    exploit? What a surprise!


SteveT

Steve Litt 

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21