On Fri, Jul 4, 2014 at 8:52 PM, Matt Oliveri <[email protected]> wrote:
> Now that I'm using your definition of "permission", I can't even tell > what we were arguing about here. Wait! We were arguing? :-) A word though about "primitive" operations. Any operation implemented by a program is necessarily constructed from the primitive operations of the runtime. One of the design axioms in KeyKOS, EROS, and Coyotos is that there is only one "rights amplifying" operation (the identifyEntry operation[s]), and we're damned queasy about that one. It actually turns out that you could do that operation without rights amplification, but you'd need to maintain a pretty monstrous capability set to do that. The reason we feel so strongly about this: If the primitive operations do not provide any means for rights amplification, then it follows that there is no way for a program to somehow escape or exceed the authority bounds presented by it's capability [set]. The only authority a program can obtain is (a) what it starts with - which in Coyotos is almost always transtively read-only, and (b) authority derived from capabilities that are passed to it in the course of its execution. This is actually a very, very powerful invariant. It means, for example, that you cannot extract a capability held by an application unless the application consents to give it to you (or is tricked into doing so). Tricking applications is harder in capability systems than it is in most other systems, exactly because permissions [in the form of authorizing capabilities] are always explicitly designated at the point of use. This is the essence of how programs can keep secrets. It's possible to imagine extending this idea to object runtimes, as in the purse example. But conversely, if the primitive operations *do* offer some means of rights amplification, you're screwed from the get-go. So following this philosophy of minimizing rights amplification, I would argue the things I have been arguing over the past day or two: that downcast and interface fetch should not be operations that are inherently permitted by the primitives of the language. At the very least, there should be a mechanism by which the programmer says "yes or no" to these operations, and also "under what conditions". I think we've talked this through at this point. The only reason I'm sending this is to try to give some sense of the relationship between the capability ideas in Coyotos and the guarded interface ideas that we have been talking about here. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
