[Python-Dev] Re: Capabilities
10 Mar 2003 12:18:29 -0500
On Sun, 2003-03-09 at 07:40, Zooko wrote:
> 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
> 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
If you need to rewrite all the libraries to be capability-aware, then
you need to trust everyone who writes library code to understand
capabilities and be thorough enough to get them right. I think this
exacerbates the current problem of restricted execution in Python: The
responsibility for making the system secure is spread through the
interpreter. To do an audit to convince yourself the system is secure,
you have to look at a lot of the interpreter. I don't see how it would
help to add the standard library to the mix.
It seems like we have a conflict between two design principles --
economy of mechanism and least privelege.
> P.S. I learned this three-part paradigm from Mark Miller whose paper with Chip
> Morningstar and Bill Frantz articulates it in more detail:
I don't see the part of this paper that talks about library design :-).
I assume that it's the first section "Only Connectivity Begets
Connectivity." But I don't know if I understand how that applies to
library design in concrete terms.