[viraptor]

Right. I think I see the difference he intends. I see this more of a practice -vs- theory issue. (Or in isolation/in deployment) In theory he can work on designing the correct version of gzip and there's a chance he'll succeed. But in practice, I'm still putting a seccomp/pledge-equivalent on it, because if he fails, I'm stopping local root escalation and potential lateral movement, which he doesn't seem to think are interesting consequences.

[geocar]

There's a point of subtlety remaining:

DJB isn't advocating against using seccomp or a pledge-equivalent.

DJB is advocating against stopping there.

[viraptor]

That's definitely not how I understand this DJB quote:

> I have become convinced that this “principle of least privilege” is fundamentally wrong. Minimizing privilege might reduce the damage done by some security holes but almost never fixes the holes. Minimizing privilege is not the same as minimizing the amount of trusted code, does not have the same benefits as minimizing the amount of trusted code, and does not move us any closer to a secure computer system.

By "does not move us any closer" I don't believe he wants us to do it at all.

[geocar]

> By "does not move us any closer" I don't believe he wants us to do it at all.

Then take a look at § 5.1 of the paper which gives a clearer example with which to draw the distinction.

Eliminating trusted code is what you're doing by decorating uncompress with pledge() with any capability to acquire resources; anything beyond stdio (or seccomp)

Minimizing privilege means focusing on finding some other argument for pledge().