Squeak-e

squeak-e@lists.squeakfoundation.org

54 discussions

Presentation on CapTP for the OMG
by Mark S. Miller 11 Feb '03

11 Feb '03

[cross-posted to e-lang and squeak-e] Last January 27, Marc Stiegler and I did a presentation on CapTP for the OMG. The presentation is available from the OMG website at http://www.omg.org/cgi-bin/doc?mars/2003-01-13 or from erights.org at http://www.erights.org/talks/captp4omg/index.html . Most of talk was spent trying to explain why distributed cryptographic capabilities are the right way to do secure distributed objects. I'd say this part went rather well. We even got some enthusiastic discussion of how the OMG might consider a Corba with cryptographic capabilities *instead* of Corba's current security. I was surprised at how plausible it seemed that this might really happen, but I have no idea what the actual politics might be. Unfortunately, but not surprisingly, we spent the entire time on the security aspects of CapTP and none on the concurrency control. In preparing the talk, I was quite happy when I drew http://www.erights.org/talks/captp4omg/captp4omg/sld019.htm to explain the concurrency control, though I never got that far in the talk. It's nicely complementary to the earlier slide http://www.erights.org/talks/captp4omg/captp4omg/sld012.htm , from the Ode, which I used to explain CapTP's security. So here's an attempt at a compact explanation of the distributed event loop part of E's concurrency control using this one slide. It doesn't say anything I haven't said elsewhere, but I do think it makes the picture as a whole clearer. This shows each vat as having an L-shaped data structure recording what remaining computations still need doing in that vat. The green blocks are stack frames, and the vertical tower of green blocks is the stack. As is traditional, the stack is shown upside down, with the top-of-stack at the bottom. The purple blocks are pending deliveries -- a record of the need to deliver a given message to a given receiver. The horizontal row of purple blocks is the pending delivery queue, ie, the event queue. Computation in each vat proceeds only at its current top-of-stack. An immediate call (".") pushes a new green block to the top of stack. Since "." can only be performed on a NEAR (intra-vat) reference, the green block gets added to the stack of the calling vat. An eventual send ("<-") enqueues a new purple block to the back of the event queue of the vat hosting the receiver. We see that Alice is currently executing in VatA, since VatA's top-of-stack points at her as receiver. In step (1), Alice executes "bob <- foo(carol)". In step (2) we see the result -- a record of the need to deliver "foo(carol)" to Bob is enqueued on VatB's queue, since Bob resides in VatB. Unshown is step (3), when computation in VatB advances till this record is at the front of the queue, whereupon it becomes the initial stack frame of a new stack, at which point Bob actually receives the message. The remaining major concepts of E's concurrency control are promises and pipelining, for which I use the graphic y'all have already seen http://www.erights.org/talks/captp4omg/captp4omg/sld020.htm (thanks Darius!). And the whole when/catch, __whenMoreResolved thing, which currently has no pictures but needs them. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Re: [Squeak-e] Draft Consensus Plan
by Anthony Hannan 10 Feb '03

10 Feb '03

"Mark S. Miller" <markm(a)caplet.com> wrote: > Do these points sound at all plausible? Does the twist sound like a good way > to proceed? Yes to both. I like it. Cheers, Anthony

1 0

Fwd: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 10 Feb '03

10 Feb '03

I just realized that Dean's message may not have been accepted by the mailing list. Apologies if you see this twice. >X-Sender: agorics(a)postoffice.pacbell.net >X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 >Date: Sat, 08 Feb 2003 13:19:06 -0800 >To: "Mark S. Miller" <markm(a)caplet.com> >From: Dean Tribble <tribble(a)e-dean.com> >Subject: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk" >Cc: Squeak-E - a capability-secure Squeak <squeak-e(a)lists.squeakfoundation.org> > > >This is a response to some comments about the importance of openness to >Smalltalk. > >One of the reasons I have not spent more time working on squeak and porting >older Smalltalk libraries and tools to Squeak is a confusion about openness >and malleability. > >Openness: > >One of the most wonderful things about a Smalltalk environment is that it is >open to inspection, modification, and extension by the developer. This >might be the single most important thing about Smalltalk. > >But it is *not* at odds with security. What is at odds with security is >confounding open-to-the-developer and >open-to-any-program-that-happens-to-be-nearby. I would like a Smalltalk >system that is open to *me* when it is running on my machine, but in which >the programs are not exposed to *each other*. (Indeed systems that try to >prevent me from seeing or manipulating things on *my* machine make me very >angry! :-) > >As MarkM says, getting back to the sense of *the developer* being able to >change anything while still preserving capability security could be >challenging. But it's a lot easier to get to a place where programs must >follow rules with each other, but development tools can get the access they >need easily. The general pattern is to replace primitives for getting >inappropriate access (e.g., instVarAt) with "closely-held" capabilities: >capabilities that are available only to a few programs, which ensure that >their use does not violate capability discipline or system integrity. > >Let's look at instVarAt: for example. It is primarily there to support >meta-level tools like inspecting and debugging. These are almost always >tools for developers, not programs. Replace instVarAt primitives with a >primitive capability that is closely held by the development tools. The >developer's tools then use that capability to look inside any object. >Normal programs don't have access to the capability, and so they cannot >violate arbitrary object encapsulation. The developer can decide to make a >new service that has that capability (e.g., an object serializer for >rewriting the Smalltalk image in a different format), but again that doesn't >mean the authority is available to the Web server. > >Malleability: > >Another important facet of Smalltalk's openness is malleability, the fact >that a programmer can change anything in the environment. Too often, people >confuse this with increasing flexibility in arbitrary dimensions, and >removing all barriers and modularity. As a result, it often seems at odds >with security. First, I'll give some examples of what I consider bogus >malleability in Smalltalk; the basic theme is that Juntas are a symptom, >not a solution. > >- When I'm refactoring the Browser, I don't want the browser I'm currently >using to break. I want to create a new version of the Browser, then try it. > >- I might want to (and have!) develop an entirely new user-interface >framework, possibly starting from the current one, without breaking my >development environment as I go. > >- At a non-gui level, I've changed the way that numbers decide on coercions, >without breaking the system. > >Doing that as Juntas just seems pointless and silly; I should be able to >produce a new system without breaking the old version. I want complete >control, without having my entire environment feel like it is made of mud >because it keeps changing out from under me (and yes, I'm exaggerating a >little for effect). > >I guess my point here is that one can have a system that is entirely >malleable to the developer, with the ability to add structured hooks >(closely held) to apply that malleability to new tools or techniques, >without having arbitrary malleability be a common element in the programming >environment. > >So the final claim is that Squeak-E could have the familiarity with >Smalltalk, with the differences only showing up for people that "open up the >hood", but those people will just open the hood in a slightly different but >still easy to understand place, and have all the power they could want. >This seems like a useful intermediate target (in the spectrum of security >targets) that would also be comfortable to the Smalltalk community. > >Comments? > > > > ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

RE: [Squeak-e] [goodie] SqueakElib released to squeak map
by Brent Vukmer 10 Feb '03

10 Feb '03

Rob -- You ought to edit the SqueakMap entry; right now it lists the URL for the asn1-encoding-dsa code as http://swiki.squeakfoundation.org/squeak-e/uploads/3/asn1-encoding-dsa.s ar instead of http://swiki.squeakfoundation.org/squeak-e/uploads/3/asn1-encoding-dsa.c s. Thanks for posting your work! Brent -----Original Message----- From: Robert Withers [mailto:rwithers12@attbi.com] Sent: Monday, February 03, 2003 5:07 AM To: Squeak-E - a capability-secure Squeak Subject: Re: [Squeak-e] [goodie] SqueakElib released to squeak map Ok, a few more tips. Once you have build the encrypted VatTP connection, you will have an inspector open on the VatTPCombinedProtocol. Go to that inspector and doit to self sendEMsg: 'hello world' in the transcript this should print out. That's it! ;-) It did get encrypted and send of course. For the CapTP there are no messages you can send but looking at the #session ivar is a good place to start exploring the structure. cheers, rob On Monday, February 3, 2003, at 04:35 AM, Robert Withers wrote: > http://swiki.squeakfoundation.org/squeak-e/3 > > sorry, no docs. > > enjoy! > > ps. you have to have the asn-encoding-dsa.cs changeset, loaded > > _______________________________________________ > Squeak-e mailing list > Squeak-e(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeak-e > _______________________________________________ Squeak-e mailing list Squeak-e(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-e

2 3

RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Withers, Robert 07 Feb '03

07 Feb '03

> -----Original Message----- > From: Anthony Hannan [mailto:ajh18@cornell.edu] > "Mark S. Miller" <markm(a)caplet.com> wrote: > > (The above argument is also bit of a preview of my upcoming > "What's Wrong > > with Dynamic Scoping?") > > I agree dynamic scoping is bad (my "smart" capabilities would have > relied on it). The only tricky thing is how to handle exceptions. Guys, I don't agree that dynamic scoping is bad, it just may not be secure in it's current form. Colin's recent comments drives this point home. If the environment isn't open from top to bottom to our investigation and modification, then it isn't going to be Smalltalk. This is a critical feature to retain. Traits, continuations and my eventual sending redirectors are other examples where either dynamic scoping or system openness are crucial to allow us the facility. The reason I include both dynamic scoping and system openness, is that the openness of Squeak _currently_ depends on dynamic scoping. We shouldn't lose this as we shift towards more security; in fact we should only extend squeak to start supporting security, and keep it backwards compatible. We can start this process by looking at providing more vm support for evental sending, finishing CapTP, and by migrating Lex's Islands work to 3.5. Thus I think the short-term (couple of months) goal should be supporting security level 2 of Mark's original proposal. > Your right, I'm giving too much authority to Kernel creators. > So instead > I propose that once a creator "releases" his class he can no longer > change it. If he wants to make revisions he has to create a new > subclass. Others may decide to use his new subclass or not. They may > migrate existing instances to the new class and/or use the > new class for > new instances. I don't like this restriction. Classes and code should be able to evolve. Now if an 'Island' has classes bound into it, those classes shouldn't change, unless the right capabilities to change them are held. I think the argument Mark is making is that there isn't a central authority. In fact, there is no third party security sever or third party interface respository. I do think that we could specify the protocols for a base library, but that's really what the ANSI spec is about. There may be some library specification additions for supporting security/eventual sends. > MarkM wrote: > > Same problem then. I think these can't be automatically > replicated, because > > there is no one authority everyone would mutually trust. At > least I hope there > > won't be. A world in which there's some one authority > everyone is willing to > > make themselves fully vulnerable to is a world ripe for > dictatorship. > > Yes, like above I will change this so no one has authority once the > pool is "released". However, I will still allow the creator > to add new > classes to a pool. This is where he could add his new > subclass versions. > Adding to a pool is benign. Again, I think that with the right capability, these things could be changed 'locally'. The issue is that there isn't a global authority. I am encouraged that although this list is turning out to be on the quiet side, there is much interest in what we are considering. The fact that we are doing so in a thoughtful way is to our advantage. I will be a little more active this weekend, now that the work week is winding down. I want to implement RemoteHandlers (virtual circuits with remote objects) and the objectMap. The other dimension, that I have been doing a little work with this past week, is cleaning up the EventualReferences. I am hanging out on the IRC channel #squeak-e and will be available there to guide anyone wanting to dive into this very intriguing mechanism. Look at ReferenceContext (the eventual reference), and RedirectionManager (the underlying redirection mechanism). If you build a redirection vm, make sure you doit to 'RedirectionManager enable'. I will update the SqueakElib package this evening. cheers, rob

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

In last paragraph of my last post Anthony Hannan <ajh18(a)cornell.edu> wrote: > Ie. all classes of possible collaborators must reside in the > method class's pool. should read: Ie. all INTERFACES (abstract classes and class extensions) of possible collaborators must reside in the method class's pool. Cheers, Anthony

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

"Mark S. Miller" <markm(a)caplet.com> wrote: > > At 09:47 PM 2/6/2003 Thursday, Anthony Hannan wrote: > >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). > > I'm still confused. How would it tell who it is being used by? Earlier I wrote: > >> [...] What do you mean by "confirm the sender"? What > >> information would you examine, and what notion of sender would you compare > >> it against? [...] > > Likewise, above you write "designated sender". Designated how? What would be > designated? Do you imagine designating the individual object that may send > to a given capability? Why would this be useful? > > > 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. I've have just realized my "smart" capabilities scheme is useless. Even if it prevents Bob from giving the capability directly to others it does not prevent him from acting on other's behalf. He could act like a forwarder for others thus giving out the capability indirectly. So please ignore my "smart" capabilities. I will remove if from my paper. Thanks for catching me on this. > Please read Capability Myths Demolished. I did. Very good paper! > The bigger issue is that with proper capability foundations, this kind of > behavior isn't possible. It would violate the encapsulation of the sender > for the receiver to know anything about the sender other than: > > * What the sender decided to send to the receiver as arguments. > * That the sender therefore must have had capabilities to these arguments > and to this receiver. > > Nothing else is the receiver's business. This information hiding allows > senders to reorganize freely the nature of the computation from which these > messages are emitted, since this change of organization can't be sensed by > the receivers. This is good modularity just as much as it is good security. Good point. I agree. > (The above argument is also bit of a preview of my upcoming "What's Wrong > with Dynamic Scoping?") I agree dynamic scoping is bad (my "smart" capabilities would have relied on it). The only tricky thing is how to handle exceptions. > As of ParcPlace 2.5, ignoring thisContext, the above properties were also > true of regular Smalltalk programming. Violating them takes us away from the > object paradigm and the capability paradigm. Yes, we will have to eliminate thisContext from Squeak-E. It should be enough to just have the following, implemented as primitives: [^ ...] (block remote return) ensure: ifCurtailed: on:do: signal. > >I threw it in as an alternative to information flow security. > > I don't know anything about information flow security. Please check out: Andrei Sabelfeld and Andrew C. Myers. Language-Base Information-Flow Security. IEEE Journal on Selected Areas in Communications, special issue on Design and Analysis Techniques for Security Assurance, 21(1), January 2003. <http://www.cs.cornell.edu/andru/pubs.html> It is interesting work and seems to be an active area of research. It relies on static typechecking of programs whose variable types have been annotated with security labels. It provides end-to-end security; information can never flow from higher to lower security, even derived information. > >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. > > Once I make the decision to install a security kernel of some sort, whether > a secure OS or language kernel, everything else I do on it is then fully > vulnerable to the misbehavior of that kernel. I'm trusting it with a lot. I > don't make that decision casually, and I make it based on my sense of the > scrutiny given to that code by an open community. > > When I make that installation decision, I make it with regard to a > particular version of the code. Granted, once I've done so, I probably > regularly decide to upgrade to the later version published by the same > organization without adequate further thought. But (at least for me), > I *must* make that decision manually each time. Otherwise, I make myself > vulnerable to the organization itself, rather than just to each individual > version of their (hopefully widely reviewed) code. Your right, I'm giving too much authority to Kernel creators. So instead I propose that once a creator "releases" his class he can no longer change it. If he wants to make revisions he has to create a new subclass. Others may decide to use his new subclass or not. They may migrate existing instances to the new class and/or use the new class for new instances. > >> 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). > > Same problem then. I think these can't be automatically replicated, because > there is no one authority everyone would mutually trust. At least I hope there > won't be. A world in which there's some one authority everyone is willing to > make themselves fully vulnerable to is a world ripe for dictatorship. Yes, like above I will change this so no one has authority once the pool is "released". However, I will still allow the creator to add new classes to a pool. This is where he could add his new subclass versions. Adding to a pool is benign. > >> 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. > > Doesn't this require selectors in the source always to be written in the > qualified form? Not if the selector by itself is unique among all possible selectors visible in the method class's pool. Remember, a method can only send selectors of abstract classes/extensions found in the method's class pool. Ie. all classes of possible collaborators must reside in the method class's pool. Internally, all selectors will be qualified (in case the pool changes) but when displayed only ambiguous selectors will need to be qualified. Of course, the user may set a preference to qualify all selectors when displayed. Thanks, Anthony

1 0

squeak-e and ANSI Smalltalk
by Allen Wirfs-Brock 07 Feb '03

07 Feb '03

I just want to mention that when I read Lex's "Object as Capabilities in Squeak" I was struck by the number of similarities between it and much of what is in the ANSI Smalltalk specification. Just as one example, in ANSI Smalltalk a reference to OrderedCollection doesn't necessarily bind to a "class object". It is simply a "named object" (a constant global binding) to an object that is required to conform to the protocol <OrderedCollection factory> and this protocol only includes a few instantiation messages. In developing the ANSI Smalltalk specification we were trying to define the core user language and protocols that is most commonly used in application programs, rather than in tools or the reflective implementation of a Smalltalk environment. To do so, we needed to strip away all the meta-level and implement artifact messages that clutter all conventional Smalltalk implementation. This sounds very similar to what you need to do to define a secure dialect of Smalltalk. If you haven't read the ANSI spec. for awhile (or ever) you might find that this perspective offers some clues to the perennial question "what were your guys smoking when you wrote that spec?". If you don't have a copy of the ANSI Smalltalk Standard a near final draft is still available at: ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.doc or ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.rtf Allen_Wirfs-Brock(a)instantiations.com

4 7

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 07 Feb '03

07 Feb '03

At 09:47 PM 2/6/2003 Thursday, Anthony Hannan wrote: >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). I'm still confused. How would it tell who it is being used by? Earlier I wrote: >> [...] What do you mean by "confirm the sender"? What >> information would you examine, and what notion of sender would you compare >> it against? [...] Likewise, above you write "designated sender". Designated how? What would be designated? Do you imagine designating the individual object that may send to a given capability? Why would this be useful? > 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. If "Bob" is an individual object, this breaks subcontracting among objects, and leads to a system that's very hard to program. If Bob is a large aggregate of objects, then we have other problems. In either case, this allowing or disallowing based on the alleged identity of the sender is the ACL paradigm. This way madness lies. Please read Capability Myths Demolished. > "Smart" is bad term. Also, hopefully this kind of >capability isn't needed in a well designed system. So let's design the system well enough that we don't need it. The bigger issue is that with proper capability foundations, this kind of behavior isn't possible. It would violate the encapsulation of the sender for the receiver to know anything about the sender other than: * What the sender decided to send to the receiver as arguments. * That the sender therefore must have had capabilities to these arguments and to this receiver. Nothing else is the receiver's business. This information hiding allows senders to reorganize freely the nature of the computation from which these messages are emitted, since this change of organization can't be sensed by the receivers. This is good modularity just as much as it is good security. (The above argument is also bit of a preview of my upcoming "What's Wrong with Dynamic Scoping?") As of ParcPlace 2.5, ignoring thisContext, the above properties were also true of regular Smalltalk programming. Violating them takes us away from the object paradigm and the capability paradigm. >I threw it in as an >alternative to information flow security. I don't know anything about information flow security. >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. Once I make the decision to install a security kernel of some sort, whether a secure OS or language kernel, everything else I do on it is then fully vulnerable to the misbehavior of that kernel. I'm trusting it with a lot. I don't make that decision casually, and I make it based on my sense of the scrutiny given to that code by an open community. When I make that installation decision, I make it with regard to a particular version of the code. Granted, once I've done so, I probably regularly decide to upgrade to the later version published by the same organization without adequate further thought. But (at least for me), I *must* make that decision manually each time. Otherwise, I make myself vulnerable to the organization itself, rather than just to each individual version of their (hopefully widely reviewed) code. >> 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). Same problem then. I think these can't be automatically replicated, because there is no one authority everyone would mutually trust. At least I hope there won't be. A world in which there's some one authority everyone is willing to make themselves fully vulnerable to is a world ripe for dictatorship. >> 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. Doesn't this require selectors in the source always to be written in the qualified form? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 07 Feb '03

07 Feb '03

Hi Mark, thanks again for your critique, here are my responses: Mark S. Miller <markm(a)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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e