[cap-talk] DJB on Least Privilege

[David Hopwood]

Toby Murray wrote:
> An interesting paper has appeared from Daniel Bernstein: "Some thoughts
> on security after ten years of qmail".
> 
> http://cr.yp.to/qmail/qmailsec-20071101.pdf
> 
> Lots of good insights. Some really good contradictions too that point
> directly to the utility of the capability-security paradigm, which is
> why I'm  mentioning it here.
> 
> He lists six principles of security, three that he believes have worked
> well and thee that he regards as a distraction from building secure
> systems.
> 
> One of those that has worked well has been to minimise the amount of
> trusted code.  
> 
>>    The third answer is to reduce the amount of trusted code 
>> in the computer system. We can architect computer systems
>> to place most of the code into untrusted prisons. “Untrusted”
>> means that code in these prisons—no matter what the code
>> does, no matter how badly it behaves, no matter how many
>> bugs it has—cannot violate the user’s security requirements
> 
> Surprisingly, he later asserts that trying to achieve least privilege
> has been one of the distracting efforts in building secure systems.

I find this odd; the only explanation I can think of is that Bernstein
is taking "Principle of Least Privilege" to mean something different
from what the capabilities community means by it.

Indeed, the example that Bernstein gives in the "eliminating trusted code"
section:

# Consider, for example, the portion of the sendmail code responsible
# for extracting an email address from the header of a mail message.
# According to [12], Mark Dowd discovered in 2003 that this code had a
# security hole:
#
## Attackers may remotely exploit this vulnerability to gain "root" or
## superuser control of any vulnerable Sendmail server. [...]
#
# Suppose that the same address-extraction code is run under an
# interpreter enforcing two simple data-flow rules:
#
#  * the only way that the code can see the rest of the system is by
#    reading this mail message;
#  * the only way that the code can affect the rest of the system is
#    by printing one string determined by that mail message.
#
# The code is then incapable of violating the user's security
# requirements.

is a absolutely typical example of the kind of technique that the
capabilities community would describe as an application of POLA.
In a capability-secure language (or in a pure functional language),
it can be implemented straightforwardly by making the address
extracter a confined (or pure) function of type MailMessage -> String.

Similarly for the jpegtopnm example in section 5.2, which assumes
the ability to run a program in a minimal-privilege environment.

-- 
David Hopwood