Hi Mark, thanks again for your critique, here are my responses:
Mark S. Miller markm@caplet.com wrote:
Anthony Hannan wrote (in his Shared Smalltalk paper): 2.2:
If you have to give out stronger capability objects, make sure the client is trustworthy, since it may pass the capability along to other objects. It is possible to create smart capabilities that confirm the sender at runtime, but this requires maintaining an access control list that is usually more trouble than handing the capabilities out correctly in the first place.
[likewise, but out of order]
In extreme cases, where you need to give a stronger capability to an untrusted client, you can have the capability check who the sender or user is as mentioned earlier. You can have it wrap all results in new capabilities that also check who the sender/user is, and so on. This provides end-to-end security without trusting client objects, albeit with extra overhead.
What problem do these "smart capabilities" solve that isn't better solved using pure capabilities? What do you mean by "confirm the sender"? What information would you examine, and what notion of sender would you compare it against? These "smart capabilities" looks to me like a mixture of capability and ACL notions. Among other things, it means that a sender effectively has extra authority because of his identity, rather than just the authority he chooses to use. This leads to confused deputy problems. In terms of Figures 3 and 4 of Capability Myths Demolished http://zesty.ca/capmyths/usenix.pdf , you have arrows pointed both ways. I think this may be approximately what Li Gong's ICAP http://citeseer.nj.nec.com/gong89secure.html tried to do.
Sorry this was not written more clearly. A "smart capability" is a revocable capability that is automatically revoked if used by someone other than the designated client (sender). If Alice gives Bob a "smart" capability to Carol. That capability will only forward messages to Carol if the message is from Bob. If Bob gives the capability to anyone else it won't work. "Smart" is bad term. Also, hopefully this kind of capability isn't needed in a well designed system. I threw it in as an alternative to information flow security.
The next paragraph beginning with
A fundamental difference
is just great. I don't remember seeing it explained this way before.
I'm glad you like it. I think the idea of objects as clients/principles and not just users/processes is the paradigm shift needed to appreciate capability security.
2.4: In E, to declare an object PassByCopy it must satisfy three conditions:
- OpenState -- all its instance variables must be accessible through its interface in a standard way. I think this maps exactly to what you're saying.
- OpenSource -- the object must make its source available through a standard request on its interface.
- Frozen -- the instance variables must be immutable. (It would be adequate to check that they aren't assigned to.)
...
If your copied objects aren't Frozen, then you'll need to coordinate distribute state, which is tricky
Yes, I'm assuming coordinated replicas which I know is tricky and therefore did not talk about it in my paper. I'm hoping classes and methods which don't change often can be replicated. PassByProxy would be used for most regular objects unless they meet the conditions you state above for PassByCopy.
3:
Since common classes are the same across users we will model them as actually being identical objects that are replicated but kept in sync [2]. This allows them to be changed together if need be by an authorized user.
Aren't the common classes common across the universe? Who would have enough authority to change these? I think I'm missing something.
Yes, common classes are common across the universe and replicated on users' machines that use them. But they still may need to be evolved, so some trusted "Squeak Central" users may have authority to change them. Their changes would be propogated to all machines that have replicas of them.
3.1: I love your description of users and portals. I think it's exactly right.
Yes, a user is just another object with it own capabilities.
3.2: Are you proposing that each pool dictionary be replicated across all users?
Yes, replicated to all users that are using them. Remember, I envision all users working on the same object graph (same Smalltalk image). Parts of the graph that a user is accessing are replicated or proxied to his machine.
If so, then these must contain no authority as you've heard me harp on.
That is where read-only classes come in (section 3.3). Each pool only contains read-only cabilities to classes. Additionally, each pool cannot be changed (elements cannot be added, removed, changed) unless someone has a capability to do so (like "Squeak Central" authority to change common classes above).
3.4: Really really cool. But, since you wish to prevent the class extension from overriding the common class it's extending, what happens if the common class later defines a method for one of the messages defined by some extension?
They would essentially be different selectors (messages). Typed-selectors (section 3.6 below) provides separate selector namespaces for each class and class extension, so there would be no conflict. A class may only be polymorphic with another class if they both inherit from the same abstract superclass (interface) that introduces the polymorphic selector. Classes and their class extensions do not inherit common selectors so they can't be polymorphic or conflict.
Polymorphism through inheritance implies tolerance for multiple inheritance. See http://minnow.cc.gatech.edu/squeak/1783 for my view of mulitple inheritance. Note, I did not propose multiple inheritance in my paper but I think I'm going to add it to make typed selectors and class extensions more complete.
3.5:
A user may also add a subclass to any class. If the superclass is read-only then the subclass can not access the superclass's instance variables or pool, only its own instance variables and pool.
If the superclass sends a message to self, does the subclass receive it, as one would naively expect?
Yes.
3.6:
Finally, if the message name is found in more than one class interface, then those classes are presented to the user for him to choose.
In this case, the choice should be represented by making the selector in the source explicit (eg, your later "collection.do"). Otherwise, the source text is not the complete source.
Yes, agreed.
It also makes detached class extensions possible.
Intriguing. How do you mean? I think this one's important to understand.
I tried to explain this at the end of section 3.4. Since each selector (message) knows which abstract class or class extension (interface) it is part of, we know if we are calling a class extension method or a regular method. If we are calling a class extension method we look through it and its subclasses for the appropriate method without looking through the base class or its superclasses (class extensions can have subclasses that mirror the subclass hierarchy of the base class). The class extension subclasses are lookuped in the same order as their base classes starting with the class of the receiver.
Cheers, Anthony
squeak-e@lists.squeakfoundation.org