[all_blue_chucks]

That's because security requires defense in depth. If the failure of a single security control can invalidate your security model, your security model is inadequate.

It should require multiple things to go wrong for catastrophic failure. This is a lesson from engineering that hasn't made its way to software development yet (outside of security engineering, anyway).

[whydoyoucare]

I believe several terms here need a context, without which they are meaningless. For example, what is an acceptable security model to download and install an OS, how do you exactly define "defense in depth" for the act of downloading and installing an OS, etc.. That will help us define what controls should be in place for the overall OS-download-and-install experience to be secure.

[all_blue_chucks]

Defense in depth is just an industry term for redundant security. For example, you can mitigate tampering with data transfers by signing the data itself AND ALSO by signing the channel it's transferred over with TLS. If a flaw is found in one of those methods, the other will still protect you.

The process of listing all the security failure points and documenting the redundant mechanisms to protect them is called threat modeling.

For a system that installs OS-level binaries as root, it would absolutely be appropriate to threat model it and hold it to a defense in depth standard. In defense systems, they often require three levels of defense in depth, the last being an air gap network.

[whydoyoucare]

Yes, this works. In theory. In practice, a simple model is needed that everyone can follow and implement consistently. That, does not exist.

Lookup "threat modeling" and you will see how abstract a notion it is (even your comment calls for a "redundant mechanism" that may not be exactly what you are looking for), and how little information is available. End result? Most do it for the "checkbox effect". Don't get me wrong, I am not trying to obliterate what you said, just putting some factual data around it.

[all_blue_chucks]

You're right that it's not simple. In fact, studying security-senstivie ways in which software tends to fail and how those failures can be mitigated is an entire field unto itself. Software developers can't be expected to get it right on their own. That's why all major software companies have security engineers on staff.

Open source projects, unfortunately, rarely have such contributors. Probably because building stuff is more fun than threat modeling (which can be quite tedious to do properly).

[blattimwind]

One really obvious thing that occurs to me is that apt uses separate processes for network I/O but fails to reduce their privileges.

[justinclift]

> If the failure of a single security control can invalidate your security model, your security model is inadequate.

As an example, when an admin gets an AWS Security Group wrong, thereby exposing database servers / redis / customer data. Consequence... multimillion $ fines, brand/reputation damage.

It's kind of sad how badly things are set up to fail sometimes. :(