[cap-talk] DJB on Least Privilege

[Jonathan S. Shapiro]

On Sat, 2007-11-03 at 16:05 +0000, Toby Murray wrote:
> > Many additional "security" efforts are applications of the "principle
> > of least privilege".
> > ...
> > These "security" efforts work as follows. We observe that program P
> > has no legitimate need to access operating-system resource R. We then
> > use (and possibly extend) operating system control to prevent P from
> > accessing R.
> 
> Of course, what he's criticising here is not least privilege, but the
> difficulty of trying to achieve it in systems that do not unify
> designation and permission. Least privilege is what he's arguing for
> above when talking about putting untrusted code into prisons of course.

I didn't read it that way. He makes the (correct) point that narrowing
the consequences of a bug isn't a substitute for fixing the bug. But he
does seem pretty dismissive about the importance of narrowing the
consequences.

What he is ignoring is that large bodies of code take overwhelming
effort to fix, and when they aren't designed for security, testability,
and verifiability in the first place, you can never know when you are
done. Narrowing the consequences really doesn't fix those bugs, but it
often helps to expose them more reliably and it certainly makes the
buggy programs less expensive until they are fixed.

All of which reminds me of an orthogonal point: people use the cost of
legacy repair as an excuse to do nothing, and routinely ignore the fact
that new programs naturally replace old at a surprisingly rapid pace.
This raises the question: why are we (i.e. the field, and particularly
academia) not focusing much greater attention on improved
software/security engineering for virgin programs?

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org