[cap-talk] Selling capabilities programming
Jonathan S. Shapiro
shap at eros-os.com
Sat Jul 21 23:20:11 EDT 2007
On Sun, 2007-07-22 at 08:22 +1000, James A. Donald wrote:
> Jonathan S. Shapiro:
> > I also encourage you to actually listen to and think
> > about the responses, which you do not appear to be
> > doing.
> In your conversation with Jed Donnelly, he demonstrated
> that controlling and tracking transfers of authority
> between entities does not change the security properties
> of the system, and that therefore such tracking and
> control is a utility of minor value, to be done
> according to convenience and feasibility, rather than an
> essential and vital characteristic.
Can you provide a URL in the archive for that conversation? I certainly
do not recall any such conclusion.
> That demonstration
> should have relegated the issue of whether capabilities
> should be "protected" to a mere implementation detail,
> one way of doing things among many, rather than a vital
> principle to be hotly defended.
The conversation that *I* recall with Jed was to determine whether the
particular encryption strategy that he used was protected. We determined
that it is.
> > Perhaps there is some other building block that you
> > think will work. If so, I would be interested to here
> > it described.
> If you say so, I will describe it in more detail...
> Consider our example of aunt Vera...
In this long (and decently well written) description of what Aunt Vera
is doing, you failed to describe a concrete mechanism. To the extent
that you approached describing one (the discussion that secrets would be
kept in ring<3, you were actually describing something similar to
Any story for security is based on a set of foundational technical
mechanisms. Please describe yours.
> > The question is: communicable to *whom*? If these
> > authorities are send to an independent party, then
> > yes, something bad has happened. On the other hand,
> > sending these authorities to a subprogram that is
> > confined and exclusively held may make a great deal of
> > sense.
> This, however, is only an argument for protected
> capabilities if one uses "confinement" in the special
> sense that assumes protected capabilities.
James: we are going in circles. You persist in misusing the term
confinement, and therefore conclude that protected capabilities are
> As Jed put it, any code that
> possesses a capability and can that can communicate with
> an entity can accomplish any bad effects by any
> communication, that it could by communicating a
> capability to that entity - thus it is impossible to
> confine and closely hold a subprogram in the required
This is complete and utter nonsense. If the initially held capability
was authorized, the subsystem was confined and confinement has not been
broken. Jed has a number of misunderstandings about this as well.
More information about the cap-talk