(I, Zooko, wrote the lines prepended with "> > ".)
Jeremy Hylton email@example.com wrote:
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.
With capabilities, as with any other security regime, you can execute code while denying it access to any of the standard libraries. However if you want to provide code access to some of the standard library's privileges without providing access to all of them, then you in any possible security regime need (a) some way to express which privileges it gets and which it doesn't, with sufficiently fine granularity that you can grant the privileges you want while excluding those you must, and (b) when actually executing the code you have to choose which specific privileges to extend.
In a capability secure language the first step, (a) is done by the language designer. Then the library designer provides a library of bundles of privileges, and then (b) a programmer executes the code, passing to that code all and only those privileges which he wants that code to have.
The library designer's job is actually pretty easy -- just: 1. try to make privileges which are likely to be wanted separately conveniently separable and 2. try to make privileges which are likely to be wanted together conveniently bundled.
If the library designers err on either side, the application programmer can patch it up. For example, suppose the library designer made it so that a single object, the "os" object, contained both the "os.system()" method and the "os.times()" method, and the programmer wants to extend the ability to get a timestamp without extending the ability to invoke arbitrary commands. (Note: I'm aware that os is a module and not an object, but for now I want to think of it as an object to be passed by reference instead of as a modules to be "import"'ed. If we continue along the cap-Python path we'll have to come back to this.)
So the programmer just defines a proxy:
class osproxy: def __init__(self, os): self.os=os def times(self): return self.os.times()
and gives an instance of osproxy instead of the os object itself. (In practice, when it is only a single method, you would of course prefer to just pass the method itself. The proxy pattern is more general.)
If the library designer has erred on the other side, making separate objects for each of a dozen different related and innocuous functions, the programmer will very likely define one object which contains all of those functions and pass a reference to that object where he would have had to pass a dozen references to a dozen functions.
I may have made too big a deal about this originally. I just spent a few minutes browsing through modindex.html (parts of which I am already intimately familiar with), and nothing jumped out at me as needing to be wrapped or refactored before it could be used in a cap-Python. Perhaps the Python Standard Library's natural modularity has already gotten us most of the way there.
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.
No, "Only Connectivity Begets Connectivity" is just the "pointer-safety" requirement -- that one can't get a reference to an object, except by either (a) creating the object, or (b) getting the reference from some other object which already had the reference.
Hm. Yes, that page doesn't really talk about library design. The authors of E performed a project  for DARPA in which they implemented a web browser which could host pluggable renderers, such that a malicious renderer was constrained in the damage it could do. (I have no idea what DARPA wants with such a thing. ;-))
The security review team at the conclusion of the project (which included great cryptographer David Wagner) wrote  that E appeared to have advanced the state of the art without breaking a sweat. The security flaws that they uncovered were mostly due to insufficient wrapping of the Java standard libraries. For example, the E folks had allowed an object to access a Java "File" object so that it could access a single file, without realizing that the Java File object has a "getParentFile()" method which returns the parent directory.
That was why I made such a big deal about the importance of a secure standard library in my previous message. (As you know, Python's file objects don't have a "getParentFile()" method, so we're already one step ahead of Java there...)