[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]
Talin
talin at acm.org
Fri Jul 7 20:17:52 CEST 2006
Brett Cannon wrote:
> On 7/6/06, Talin <talin at acm.org> wrote:
>> And if we can call it for every operation, then we don't have to spend
>> time hunting down all of the possible loopholes and ways in which 'file'
>> or other restricted objects might be accessed.
>
> Not true. You have to set this object restriction flag, right? What
> happens if you don't set it on all of the proper classes/types? You end up
> in the exact same situation you are with crippling; making sure you cover
> your ass with what you flag as unsafe else you risk having something get
> passed you.
But that's a much simpler problem.
With the restricted flag, it isn't just *your* code that is prevented
from using 'file' - it's *all* code. Only approved gateways that remove
the restriction (by setting the interpreter state) can perform
operations on file objects without blowing up.
This means that if you call some random library function that attempts
to open a file, it won't work, because the random library function is
still running in restricted mode.
Similarly, if you have a reference to some externally created object
that has a reference to a file (or the file class) somewhere in it's
inheritance hierarchy, any attempt to access that object will fail.
Without this, you would have to chase down every bit of library code
that opens file, or has a reference to a file.
What I am proposing shares some aspects of both the crippling and the
capability model:
It's similar to crippling in the sense that you're protecting the object
itself, not access to the object. So you avoid the problem of trying to
figure out all of the possible ways an object can be accessed.
However, where it resembles capabilities is that its an 'all or nothing'
approach - that is, you either have access to file, or you don't. Unlike
the crippling model where fine-grained access control is implemented by
modifying individual methods of the crippled object, in this scheme we
cripple the object *entirely*, and then provide fine-grained access
control via wrappers. Those wrappers, in turn, act just like
capabilities - you can have different wrappers that have different sets
of access permissions.
So it provides the advantage of the capability approach in that the set
of restrictions can be extended or modified by writing new wrappers.
Thus, by providing an extremely simple but unbreakable check at the
interpreter level, we can then write classes that build on top of that a
richer and more sophisticated set of permissions, while still
maintaining a strong barrier to unauthorized actions.
-- Talin
More information about the Python-Dev
mailing list