[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Anthony Hannan]

Hi Mark, thanks again for your critique, here are my responses:

Mark S. Miller <markm at 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