DJB is drawing a distinction between two designs in his paper.
1. Netscape had a "dns helper" -- which ostensibly could only do DNS lookups, is designed in the principle of least privilege.
2. Ariel Berkman's xloadimage implementation -- which implements every image loader as a separate filter in a separate process who can do nothing but input image data and output image data (in the "common" format), is designed around eliminating trusted code.
The former could (and did) suffer a bug that affected DNS lookups, and was convinced to perform all sorts of network traffic since, it by definition needed to perform network activity to do it's function, and it could access files like resolv.conf because again, it needed to do that to perform it's function. That it couldn't be exploited to "yield root" wasn't really relevant, since most people didn't run Netscape as root. It could read user files and ship them over the Internet which is frankly bad enough.
I would argue that both are designed following the principle of least privilege. Netscape haven't had the luck of having correct code. So what would have helped in Netscapes case? How would eliminating trusted code work in this case? Netscape has to do DNS lookups. I'm not sure if there was much more left to do as writing secure correct code. And of course you should prioritize writing secure correct code over implementation of least privilege. That doesn't make the principle of least privilege fundamentally wrong.
My opinion is that if you design your software securely threat modeling should result in the decision of implementing the least privilege principle and whether it makes sense and benefits (complexity vs benefit) or not. Of course you better eliminate trusted code so that there are less case where you have to get to these decisions.
I assume that soon or later, there are situation, where you can't eliminate trusted code and it makes sense to implement least privilege.
> I would argue that both are designed following the principle of least privilege.
Okay, but that's not what DJB means, and attempting to read his words with the definitions in your head, instead of the definitions in his head won't help you understand him.
I'm not going to humour an argument about mere semantics: For the purposes of this discussion they are not both the "principle of least privilege".
> So what would have helped in Netscapes case?
Writing the DNS client correctly.
DJB's point is that absolutely nothing else would help: You can't realistically put a box around buggy code as long as the code needs privileges.
And all that effort in writing that sandbox? A waste of time; fundamentally the wrong thing to focus on. Writing a DNS client is far less work.
> I assume that soon or later, there are situation, where you can't eliminate trusted code and it makes sense to implement least privilege.
That was what DJB assumed when he wrote Qmail, however he is now convinced that was wrong. His paper gives some explanation why.
If you can't eliminate trusted code, and it's still big enough you think there might be bugs hiding inside, you should rethink your design.
1. Netscape had a "dns helper" -- which ostensibly could only do DNS lookups, is designed in the principle of least privilege.
2. Ariel Berkman's xloadimage implementation -- which implements every image loader as a separate filter in a separate process who can do nothing but input image data and output image data (in the "common" format), is designed around eliminating trusted code.
The former could (and did) suffer a bug that affected DNS lookups, and was convinced to perform all sorts of network traffic since, it by definition needed to perform network activity to do it's function, and it could access files like resolv.conf because again, it needed to do that to perform it's function. That it couldn't be exploited to "yield root" wasn't really relevant, since most people didn't run Netscape as root. It could read user files and ship them over the Internet which is frankly bad enough.
The latter, is what DJB is recommending.