[eduction]

> It hasn't aged well.

You’re wrong, it’s aged quite well.

Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for condescending security experts who think little about the broader context in which they operate. As much as we all appreciate the whack a mole.

Where there has been genuine security improvement is where we’ve taken the structural, locked down approach advocated here (see also djb’s paper about qmail security). iOS and Android apps (particularly the former) seem genuinely more secure than most desktop apps because they are structured to have very limited permissions from day one. The app environments on those systems looks like they were designed with many of the principles from this post expressly in mind.

The lessons for the OS layer seem obvious. Qubes and in particular Joanna’s post about “Qubes Air” point in one very promising direction.

[UncleMeat]

Offensive research is what motivates lessons for the OS layer. Look at the struggles were are having with things like kernel-level memory safety even when we can point at mountains of CVEs found by white hats. The community would be dragging its feet even more if the shared consensus was that actually it is really hard to beat ASLR and DEP so we are all done and have solved it.

[tptacek]

One of the major points of the qmail paper is that the structural locked down approach wasn't successful.

(I disagree with the paper in this regard, but it's a weird thing to hang your argument against vulnerability research on).

Georgi Guninski would have a thing or two to say about the applicability of vulnerability research to djb software.

[eduction]

Hi, that’s an interesting assertion but not actually accurate. It is vaguely related to the truth; djb acknowledges that qmail failed to partition in the way he advocates in the paper but says it survived without serious security issues for other reasons:

“ I failed to place any of the qmail code into untrusted pris- ons. Bugs anywhere in the code could have been security holes. The way that qmail survived this failure was by hav- ing very few bugs, as discussed in Sections 3 and 4.”

That’s very different from saying the approach wasn’t successful. It was just not tried (by him). My point is it has been tried in other ways since and seems to be working. To me at least!

(Also you took something I put in parens midway through my post with the opening words “see also” and said I “hang” my argument on it - ok, again interesting, not taking it personally as I’m sure you didn’t mean anything by it!)

[tptacek]

It didn't "survive" in that manner: it wasn't LP64 clean, and had memory corruption vulnerabilities.

[eduction]

You described something the qmail paper said and I corrected you. If the paper is inaccurate that’s orthogonal.

[tptacek]

You're also incorrect about the paper.

Really, the whole argument you're making --- the reason we're talking about Bernstein in the first place --- is broken. Bernstein himself would probably not agree with the take you're trying to derive from the relationship between his work and "enumerating badness".

[wildmanx]

> > It hasn't aged well.

> You’re wrong, it’s aged quite well.

Part of the problem is that there are many people in the field of security with overly strong opinions. This is not healthy. The field is full of know-it-all people, with if-only-people-were-not-as-dumb kind of attitudes. This is not helping anybody. Any not-as-strongly-opinionated bystander looks at this and has no clue whom to listen to, since so many people are strongly expressing 100% opposing views. Calling everybody else "dumb". This is not helpful to bring the field as a whole forward.

[rfoo]

> (see also djb’s paper about qmail security)

You mean the guy who refused to fix an integer overflow bug, claiming it isn't practical to exploit then 64-bit really happened then years later suddenly the fine guys at Qualys decided to have fun? [1] Sure, he is a crypto expert and we're all grateful for his work on curve25519, salsa/chacha, nacl, djbsort, etc (and I'm sure I missed a lot). This does not mean he is an expert on weird machine.

[1] https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...

[eduction]

No, I don’t mean the guy. I mean the paper.