Sunday, January 05, 2025
Security Theater
Also, Linux is getting a landlock thing, which sounds maybe a bit like
unveil
. Are they likewise deluded, or maybe there's something useful about this class of security thingymabobber, especially with “defense in depth” in mind?
An aspect I think you are discounting is the effort required to implement the mitigations.
While plege()
and unveil()
are simple to use,
their implementation is anything but.
Just from reading the man pages,
it appears there are exceptions,
and then exceptions to the exceptions,
that must be supported.
What makes Linux or OpenBSD different than other pieces of software,
like openssl
?
Sure, such things help overall but as you state, there are tradeoffs—and a big one I see is adding complexity to an already complex system. And in my experience, security makes it harder to diagnose issues (one exaple from work—a piece of network equipment was “helpfully” filtering network traffic for exploits, making it difficult to test our software properly, you know, in the absense of such technology).
A different take is that
pledge
andunveil
, along with the various other security mitigations, hackathons, and so forth, are a good part of a healthy diet. Sure, you can still catch a cold, but it may be less bad, or have fewer complications.
I also think you are discounting the risk compensation that this may cause With all these mitigations, what incentives are there for a programmer to be careful in writing code? One area I think we differ in is just how much of a crutch such technology becomes.
If you don't want that defense in depth, eh, you do you.
It's less that I don't want defense in depth (and it's sad to live in a world where that needs to be the default stance) but that you can do everything “by the book” and still get blindsided. I recall the time in the early 90s when I found myself logged into the university computer I used and saw myself also logged in from Russia, all because of a Unix workstation in a different department down the hall had no root password and running a program sniffing the network (for more perspective—at the time the building was wired with 10-Base-2, also known as “cheap-net,” in which all traffic is transmitted to all stations, and the main campus IT department was more concerned with its precious VAX machine than supporting departments running Unix).
My first encounter with the clown show that is “computer security” came in the late 90s. At the time, I was working at a small web-hosting company when a 500+ page report was dumped on my desk (or rather, a large PDF file in my email) with the results of a “PCI compliance scan” on our network. It was page after page of “Oh My God! This computer has an IP address! This computer responds to ping requests! Oh My God! This computer has a web site on it! And DNS entries! Oh My XXXXXXX God! You handle email!”
For. Every. Single. Web. Site. And. Computer. On. Our. Network.
It was such an obviously low effort report with so much garbage, it was difficult to pull out the actual issues with our network. You know what would have been nice? Recognition what we were a web hosting company in addition to handling email and DNS for our customers. Maybe a report broken down by computer, maybe in a table format like:
IP address | protocol/port | port name | notes |
---|---|---|---|
192.0.2.10 | ICMP echo | ping | see Appendix A |
TCP port 22 | SSH | UNEXPECTED—see Appendix D | |
TCP port 25 | SMTP | Maybe consolidate email to a single server—see Appendix B | |
TCP port 53 | DNS | DNS queries resolve—see Appendix C | |
UDP port 53 | DNS | DNS queries resolve—see Appendix C | |
TCP port 80 | HTTP | ||
TCP port 443 | HTTPS | ||
192.0.2.11 | ICMP echo | ping | see Appendix A |
TCP port 22 | SSH | UNEXPECTED—see Appendix D | |
TCP port 25 | SMTP | Maybe consolidate email to a single server—see Appendix B | |
TCP port 53 | DNS | DNS queries resolve—see Appendix C | |
UDP port 53 | DNS | DNS queries resolve—see Appendix C | |
UDP port 69 | TFTP | UNEXPECTED—see Appendix D | |
TCP port 80 | HTTP | ||
TCP port 443 | HTTPS |
Where Appendix A could explain why supporting ping
is questionable,
but allowable,
Appendix B could explain the benefits of consolidating email on a machine that doesn't serve email,
and Appendix C could explain the potential data leaks of a DNS server that resolves non-authoritative domains,
which in our case,
was the real issue with our scan but was buried in just a ton of nonsense results with the assumption that we have no clue what we're doing
(at least, that's how I read the 500+ page report).
The hypothetical report above shows SSH being open on the boxes—fair enough. A common security measure to to have a “SSH jump server” that is specifically hardened to only expose SSH one one host, and the rest only accept SSH connections on a (preferrably) separate “management” interface with private IP addresses. And oh, we're running TFTP on a box—again we should probably have a separate system on a “management” interface running TFTP to backup our router configs.
But such a measured, actionable report takes real work to generate. Much much easier to just dump a raw network scan with scary jargon.
And since then, most talk of “computer security” has, in my experience, been mostly of the breathless “Oh My God You're Pwned!” scare tactic variety.
My latest encounter with “computer security” came a few years ago at The Ft. Lauderdale Office of the Corporation, when our new Overlords wanted to change how we did things. The CSO visited and informed us that they were going to change how we did security, and in the process make our jobs much more difficult. It turns out it wasn't because our network or computers were insecure—no! Our network had a higher score (according to some networking scoring company—think of the various credit scoring companies but for corporate networks) than our new parent company (almost a perfect score). No, it came down to “that's not how we do things. We're doing it, our way!” And “their way” was just checking off a list of boxes on some list as cheaply as possible.
I think another way we differ is in how much we think “computer security” has become a cargo cult.
Update on Monday, January 6th, 2025
This thread on Lobsters is a perfect example of the type of discussion I would like to see around security. Especially on-point is this comment: “… the [question] I was actually asking: ‘Why is it dangerous, so I can have a better mental model of danger in the future?’”