[Python-Dev] Re: Capabilities
Zooko
zooko@zooko.com
Sun, 09 Mar 2003 07:40:23 -0500
To enforce capability access control, a language requires three things:
1. Pointer-safety. (There must not be a function available which performs the
inverse of id().) Python has pointer-safety (unless a 3rd party native
extension module has been executed).
2. Mandatory private data (accessible only by the object itself). Normal
Python doesn't have mandatory private data. If I understand correctly, both
rexec and proxies (attempt to) provide this. They also attempt to provide
another safety feature: a wrapper around the standard library and builtins that
turns off access to dangerous features according to an overridable security
policy.
3. A standard library that follows the Principle of Least Privilege. That is,
a library full of tools that you can extend to an object in order to empower it
to do specific things (e.g. __builtin__.abs(), os.times(), ...) without thereby
also empowering it to do other things (e.g. __builtin__.file(), os.system(),
...). Python doesn't have such a library.
Now the Principle of Least Privilege approach to making a library safe is very
different from the "sandbox" approach. The latter is to remove all "dangerous"
tools from the toolbox (or in our case, to have them dynamically disabled by the
"restricted" bit which is determined by an overridable policy). The former is
to separate the tools so that dangerous ones don't come tied together with
common ones. The security policy, then, is expressed by code that grants or
withholds capabilities (== references) rather than by code that toggles the
"restricted" bit.
Of course, you can start by denying the entire standard library to restricted
code, and then incrementally refactor the library or wrap it in Least-Privilege
wrappers.
Until you have a substantial Least-Privilege-respecting library you can't gain
the big benefit of capabilities -- code which is capable of doing something
useful without also being capable of doing harm. (You can gain the "sandbox"
style of security -- code which is incapable of doing anything useful or
harmful.)
This requirement also means that there can be no "ambient authority" --
authority that an object receives even if its creator has given it no
references.
Regards,
Zooko
P.S. I learned this three-part paradigm from Mark Miller whose paper with Chip
Morningstar and Bill Frantz articulates it in more detail:
http://www.erights.org/elib/capability/ode/ode-capabilities.html#patt-coop