From shapj:
> At Mark's request, I'm following up to my own
> earlier comments on droplets.
Thank you for taking the time to look at my work.
I'll try to address the issues you've raised.
> Editorial:
>
> There are some important inaccuracies on the
> Droplets pages. Much as I
> cherish him, Norm did NOT invent much of
> capability-based security.
Most of what I know about capability based security seems to trace back to work done by Norm. You've been studying capabilities for longer and might have a better overview of the field. Would you like to suggest a phrasing that you'd feel more comfortable with? It would be nice if you could also send me short bios and names for the other people you feel should be mentioned in my 'history' section.
> Similarly, on the main page, the statement "The
> capability model is the
> only proven, successful model for computer
> security." is simply untrue.
I would like you to make an argument for another security model before I agree to change this statement. To the best of my knowledge, capability security is the only computer security model that does not contain a fatal flaw.
You will not be able to convince me that ACLs are not a flawed security model.
> I
> believe that it is important not to overstate the
> case on these things,
> lest our community lose credibility. Let us
> instead confine ourselves
> strictly to statements that are accurate and defensible.
I believe my statement is accurate and highly defensible.
As much as you think it is important for the capability community not to overstate its case, I think it is important that the capability community not understate its case. Capability security is the most highly evolved and widely ignored security model. This has to change. If we don't let the world know just how functional this technology is, we will never see wide deployment.
> Originality:
>
> Droplets is not the first system to use this kind
> of mechanism. While the
> specific encodings are different, the Lotus
> Domino server uses an
> essentially similar mechanism for naming Notes
> objects in web-based
> presentation -- even the format of the URL is
> highly similar. The Domino
> server, however, is not using swiss numbers; it's
> capabilities are purely
> object identifiers. Permission checking in
> Domino is done based on the
> session (and therefore on the user identity).
The second half of this argument seems to completely contradict the first half. If Domino URLs do not contain a Swiss number (or some feature that makes them unguessable) then they are not capabilities. If permission checking is done based on the session, then it sounds like an ACL system. Session identifiers are also more guessable than Swiss numbers, so this ACL system might be insecure.
> Security:
>
> Here I find that my initial impression of
> Droplets is correct, though I
> think my concerns could readily be addressed.
> Droplet capabilities are
> unforgeable, but they are not partitioned.
> Because they are simply data,
> there is no way to restrict their transfer once
> they escape into the world.
This is the delegation argument. I'll state my view on this subject here. Droplets(TM) implements my view on this subject.
The creator of an object receives the only capability for that object. If the object creator wishes to share this object with another user, then it is necessary for the creator to completely define what she means by 'share'.
The most primitive form of sharing is to give another user exactly the same rights to the object that you have. This sharing policy corresponds to giving another user a copy of your capability to the object.
Using protection proxies, it is possible to implement a wide variety of sharing policies. Rights can be made revocable, time limited, additionally authenticated, etc.
If ACL style user authentication is desired, then this can be implemented in the protection proxy. It is not the place of the execution environment to dictate the sharing policy that will be used in all cases. Instead, the execution environment should provide a flexible mechanism for defining sharing policies. This flexible mechanism is raw capabilities.
> From my reading of the description at
> http://www.waterken.com/Droplet/index.html (which
> I may have understood
> incompletely), the session-independent
> capabilities remain valid
> independent of any particular session. On the
> one hand the droplet
> capabilities cannot be forged, but on the other
> they cannot be trusted as a
> means of security because there is no way to
> constrain their propagation.
The execution environment must ensure that a capability is only given to the object creator. Beyond this, the execution environment should butt out. It is up to the user to decide how they want to share their information.
If the user grants other users more access than she really wanted to, it is not a flaw of the execution environment. It is either a flaw in the application design or the user's judgement.
> Once they are out in the world, one may safely
> attribute to them only those
> qualities normally attributed to object identifiers.
I have never seen any system that attributed 'object identifiers' with the properties of capabilities. Please tell me what you think object identifiers are and list their properties. Then list the properties of a capability and mark the differences.
> Droplet's session-only capabilities, when running
> over an SSL link, provide
> a kind of partitioning for droplet capabilities,
> though hostile programs
> might still act from the client side by
> piggybacking on the session.
If the client's computer has been compromised, then the attacker gets all of the client's authority. This is just real world fact. It's a fool's game to try to defend a broken TCB.
> This
> is a significant narrowing of exposure, and
> potentially very valuable.
> This is the part of Droplet that most appeals to
> me. The piece that seems
> to be missing is a private transform that will
> let me translate a new type
> of sessionless capability (let's call it an
> unauthenticated capability)
> into a session-local capability, and a
> corresponding public transform that
> will let me turn the session-local capability
> back into an unauthenticated
> capability.
The com.waterken.sea.permit.Exporter class implements exported capabilities for the Droplets(TM) environment. It has both of the transforms that you mention.
In the Beach Sex Demo, both of these transforms have been exposed. Try using the Sturdy Maker in your menu (the link is called beachsex).
> In its current form, Droplets has some
> potentially very useful properties:
...
> + It can be used to extend the web URL space to
> generalized object
> identifiers (128 bits might be too small, but not
> because of security).
I don't understand the 128 bit statement. Keep in mind that the Swiss number alone is not the capability. The whole URL is the capability. The Swiss number identifies an object within a particular session, in a particular database, in a particular zone, on a particular server. 2^128 objects exported by a particular session is inconceivable, making the Swiss number more than adequate for security and much more than adequate for addressing.
More than extending the web URL space into a generalized object space, Droplets(TM) extends the web URL space into a capability environment (where most of the capabilities have been statically published, thus losing their authentication properties). Droplets(TM) provides a way to introduce secure capabilities into this capability environment.
Think of the current web in terms of a programming language where, until now, all programmers were only using static variables. Droplets(TM) gives them a way to use instance variables.
> [and probably others as well; this is only what
> struck me first.]
The only property that Droplets(TM) is currently missing is confinement. This means that is it impossible to run code received from untrusted sources. I believe we can go a long way towards implementing true electronic commerce on the web before we feel constrained by this missing functionality.
> So in summary: I think this mechanism is
> interesting and valuable, and that
> it is very much worth looking at. I think it is
> the start of a usable,
> general security mechanism. I think further work
> is needed to really bring
> it to fruition. I even think I would like to
> help. Whether IBM will let
> me is another question.
It seems to me that you are mostly concerned by the lack of stock objects for implementing various sharing policies. It is my intent to eventually release a paper on 'capability design patterns' as well as a library of stock objects for the Droplet(TM) environment. If you would like to assist in this, your help would be greatly appreciated.
There are also a bunch of other stock objects that need to be written. I am essentially creating a new application platform from scratch. Anyone else who would like to be involved should feel free to contact me.
In terms of Droplets(TM) itself, I have already implemented the execution environment that I wish to base my software on. I do not intend to modify it further. I believe the design of Droplets(TM) is the correct choice for applications written in Java.
Tyler