Ka-Ping Yee wrote:
Wow, how did this topic end up crossing over to this list while i wasn't looking? :0
Ben Laurie wrote:
I'll admit to being that person. A capability is, in essence, an opaque bound method. Of course, for them to be much use, you want the system to provide some other stuff, like not being able to recreate capabilities (i.e. you get hold of them from on high, and that's the _only_ way to get them).
Jeremy Hylton wrote:
That seems like a funny defintion of a capability.
A better definition of "capabilitiy" is "object reference".
"Bound method" isn't enough, because a capability should be able to have state, and your system should have the flexibility to represent capabilities that share state with other capabilities, or ones that don't. The simple, straightforward way to model this is to just equate the word "capability" with "object reference".
You can it that way, too, but it strikes me as more unwieldy in practice. A bound method also has state because it is, of course, bound to an object reference, so I find that a more elegant way to do it.
A capability system must have some rules for creating and copying capabilities, but there is more than one way to realize those rules in a programming language.
I suppose there could be, but there is really only one obvious way: creating a capability is equivalent to creating an object -- which you can only do if you hold the constructor. A capability is copied into another object (for the security folks, "object" == "protection domain") when it is transmitted as an argument to a method call.
To build a capability system, all you need to do is to constrain the transfer of object references such that they can only be transmitted along other object references. That's all.
The problem for Python, as Jeremy explained, is that there are so many other ways of crawling into objects and pulling out bits of their internals.
Off the top of my head, i only see two things that would have to be fixed to turn Python into a capability-secure system:
1. Access to each object is limited to its declared exposed interface; no introspection allowed.
2. No global namespace of modules (sys.modules etc.).
If there is willingness to consider a "secure mode" for Python in which these two things are enforced, i would be interested in making it happen.
I believe you just described rexec. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff