[cap-talk] Lampson: Principle Of Least Privilege as damaging

[Pierre THIERRY]

Scribit Jed Donnelley dies 06/04/2008 hora 13:14:
> So I say absolutely not least privilege, [...].  I think there's a lot
> of empirical evidence that tells us now that it's right.

I suspect that Lamport here has a bias, in that the only systems he
knows, for they are mostly the only ones you can see currently, are ACL
systems. ACL systems are to security policies what state machines are to
algorithms: a very limited vocabulary. In this regard, Ocaps truly are a
programming language to express security policies. I think it was a
point discussed in MarkM's thesis, that Ocaps enable the creation of
security abstractions.

In most mainstream systems that I know of, fine grained security indeed
is mostly impossible to manage. In the limited domain of those ACL
systems that are currently used, maybe Lamport is totally right. It may
take a lot of wizardry and hard efforts to get POLP right with them.

There are empirical evidence that POLP is very useful to increase
security: the qmail SMTP deamon is a good example. The $500 reward for a
remotely exploitable security hole is still unclaimed. It had been
brought to $1500, and the additional $1000 have been given to the FSF
after being unclaimed for during one year. If you read about qmail's
design, it is a typical example of POLP. When you see the sad state of
security of SMTP deamons, it advocates for POLP.

What is interesting, then, is that having done qmail, it's author seems
to advocate that POLP is not the way to go. Its reason is that it is
insanely hard to do in current systems.

So I think that both Lamport and the Ocaps community are right to
respectively fight against and for POLP. It's a matter of definitions
and domain of applicability of our claims. POLP/POLA may not be
applicable to ACL systems, and the observation of POLP's inherent
complexity may not be applicable to capability systems.

Harmoniously,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20080407/e79533af/attachment.bin