[Dev] risks [was (db policy) transparent persistence]

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Wednesday, November 27, 2002, at 05:55  PM, David McCusker wrote:

> This reminds me of a brief topic in a conversation with Andy Hertzfeld,
> where we entertained the idea of adding capabilities to Python (and I
> suggested we ask Paul Snively what he thought of that, since it's a 
> topic
> I'd expect to be dear to his heart :-).  It capabilities are not built
> in a the most primitive level, I don't suppose it's easy to add them
> higher up and actually have them be secure.
>
Funny you mention this, as I've given this quite a lot of thought. :-) 
My immediate reaction is that precisely because Python is as dynamic as 
you've observed, you should be able to relatively readily implement a 
security kernel in the sense of 
<http://www.mumble.net/jar/pubs/secureos>. It's helpful if you think of 
objects as collections of lambda expressions closing over their state, 
and introduce the notion of "facets," which can restrict the exposure 
of the lambda expressions and state of underlying objects that they 
encapsulate. Make these object references unforgeable, which I believe 
Python already does, and you have the essence of capability security. 
The next step is to extend this to distributed objects. At this point, 
I wave my hands and refer interested parties to 
<http://www.erights.org> and its mailing list. Look for discussions 
about the "VLS" (Vat Location Service) and the various flavors of 
distributed object references.

> We probably don't have time to come up with a whiz bang security model
> that partitions the world into different trust levels, at least not
> in the first cut, unless someone can start presenting a story about how
> this works that sounds clear to the rest of us.
>
Short of going capabilities from first principles, you can get awfully 
close, and implement essentially arbitrary trust models, with the 
KeyNote system. See <http://www.cis.upenn.edu/~keynote>.

>> Zope does have a sophisticated ACL model
>
> I hate to say this, but sophisticated suggests complex with a learning
> curve that helps prevent adoption by folks who want a simple system.
>
To make matters even worse, ACLs are fundamentally broken as a security 
paradigm. See <http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html> 
for an explanation of the Confused Deputy problem that all ACL systems 
suffer from. See <http://www.erights.org/elib/equality/grant-matcher> 
for an excellent discussion of issues of object identity, equality, and 
security.

> David

Best regards,
Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)

iEYEARECAAYFAj3lkWcACgkQaJiHXZZgnpgTeQCgl93KPtXibPmgRcV7kT/cL82d
J3gAoJ89jaMuAwK+7d29uTYe9/sSSw5q
=VUky
-----END PGP SIGNATURE-----