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 > 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.) 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: > > http://www.erights.org/elib/capability/ode/ode-capabilities.html#patt-coop 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. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4