[cap-talk] Plugging the YURL leak -- back to the beginning

[Tyler Close]

Hi Rob,

On 11/29/05, Rob J Meijer <rmeijer at xs4all.nl> wrote:
> A) Unbound YURLs, that could be copied serialized printed etc, and
>    are thus not capabilities in any true sense, but just password
>    capabilities, that have been shown to be limited in use and conceptualy
>    broken, given that they implicitly cary the right to grant access
>    together with the right to exercise access. Although broken thus they are
>    considdered practical by many on the list, and have shown to be usable
>    within a subset of POLA system designs. Given this, unbound YURLs remain
>    just password capabilities, not true capabilities, and should thus be
>    used with extreme care if at all.

I have studied capability-based security for many years now and am
unfamiliar with the research you are referring to. Your claim that a
password capability is not a capability because "they implicitly cary
the right to grant access together with the right to exercise access"
seems particularly bizarre since support for delegation is part of the
essence of being a capability. Do you have a reference for research
that claims that a password capability is not a true capability?

For a distributed capability implementation, which is what we are
discussing, a password capability is almost the best that can be
achieved. If you assume an attacker with read-only access to only part
of your machine, then a partitioned (or protected) capability design
has some advantages over a password capability design. However,
implementing partitioned capabilities requires specialized hardware
which is not widely deployed and special reference passing semantics
in your application protocol. HTTP does not support these special
reference passing semantics. Further, if the attacker has write access
to part of your machine, the partitioned capability design cannot make
any stronger security guarantees than a password capability design
can.

To implement partitioned capabilities over HTTP, you would need to:
redesign HTTP (or tunnel a new protocol over it), deploy new client
hardware, define a browser interface to this hardware, deploy new web
browsers. In contrast, the cap URLs I propose in the web-calculus work
with today's infrastructure and can be made just as secure, except
under the assumption of an attacker with read-only access to only part
of your machine. Given these options, I would rather pursue the
password capability design and work to avoid giving attackers read
access to my machine. The effort involved in the other approach seems
greater than that required to implement a secure os which would not
grant read access to attackers, which is something we want anyways.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957