Thoughts on droplets

[Tyler Close]

>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.

If the creator wishes to implement a more restrictive form
of sharing, then she must create a protection proxy object
that defines this sharing policy. Only the capability for
this protection proxy should be given to the other user.

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


__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com