Security Theater

* * * * *

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 [1]”

An aspect I think you are discounting is the effort required to implement the
mitigations. While plege() [2] and unveil() [3] 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 [4]?

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 [5] 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 [6] 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 (Information Technology) 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 (Portable
Document Format) file in my email) with the results of a “PCI (Payment Card
Industry) compliance scan” on our network. It was page after page of “Oh My
God! This computer has an IP (Internet Protocol) address! This computer
responds to ping requests! Oh My God! This computer has a web site on it! And
DNS (Domain Name System) 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:

Table: Hypothetical report of a network scan
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 (Trivial File Transport Protocol) 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 (Chief Security Officer) 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 6^th, 2025

This thread on Lobsters [7] is a perfect example of the type of discussion I
would like to see around security. Especially on-point is this comment [8]:
“… the [question] I was actually asking: ‘Why is it dangerous, so I can have
a better mental model of danger in the future?’”

[1] gemini://thrig.me/blog/2025/01/05/tradeoffs.gmi
[2] https://man.openbsd.org/pledge.2
[3] https://man.openbsd.org/unveil.2
[4] https://en.wikipedia.org/wiki/Heartbleed
[5] ttps://en.wikipedia.org/wiki/Risk_compensation
[6] gopher://gopher.conman.org/0Phlog:2009/11/03.1
[7] https://lobste.rs/s/uzyyf4/story_on_home_server_security#c_kcz37o
[8] https://lobste.rs/s/uzyyf4/story_on_home_server_security#c_svclfm

Email author at [email protected]