The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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?

Tradeoffs

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 and unveil, 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 XXXXX­XX 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:

Hypothetical report of a network scan
IP addressprotocol/portport namenotes
192.0.2.10ICMP 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 443HTTPS
192.0.2.11ICMP 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 443HTTPS

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?’”

Obligatory Picture

Dad was resigned to the fact that I was, indeed, a landlubber, and turned the boat around yet again …

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2025 by Sean Conner. All Rights Reserved.