[e-lang] Fwd: Capability Systems and Concurrency
Mark Miller
erights at gmail.com
Tue Mar 4 00:23:40 EST 2008
6 of 6
---------- Forwarded message ----------
From: Kris Zyp <kzyp at sitepen.com>
Date: Mon, Mar 3, 2008 at 7:49 PM
Subject: Re: Capability Systems and Concurrency
To: Mark Miller <erights at gmail.com>
Cc: Kevin Reid <kpreid at mac.com>
Thanks for explanations, I understand much better now. A few other comments
inline:
>> think the persistence of JavaScript functions in object graphs would be
>> particularly interesting to intersect with capability-based security.
>
> Indeed! One of the issues the Caja project is currently wrestling with
> is what to do about persistence.
Yes, I would love to collaborate on some of this stuff, I will join the Caja
discussion group, so I can start listening in on the discussions.
Interestingly, AFAIK, Caja and Persevere are the two most extensive
projects/efforts in JavaScript translation. Persevere does extensive
rewriting of property access in order to monitor property changes to achieve
orthogonal persistence, and detect lazy loaded property access, and does
translation to facilitate continuations (based on Narrative
JavaScript/JavaScript Strands) to load persistent properties with
asynchronous XHR transparently. And from what I understand Caja does some
similar property access rewriting.
>
>
>> One
>> could allow less-trusted sources to store functions, and their
>> capabilities
>> could be appropriately limited.
>
> I don't understand this. Can you expand?
This is really no different than the general goal of capability-based
system, untrusted code should only be given as much capability as necessary.
With my project the untrusted code can simply be persisted as well. In
Persevere, I have adopted a persistence strategy similar to that used by
some Smalltalk and Lisp implementations, where application data (objects)
and program code (functions) are not differentiated in their ability to be
persisted. Basically any JavaScript object can be fully persisted (prototype
chains, methods, et al) into the central persistent store on the server.
Persevere also implements security that can be defined for any set of
objects, and a set of objects can locally managed by user/group without
requiring access to rest of the persisted object graph. However, I can't
truly allow full access to persisting functions to users that have limited
access, because normal JavaScript essentially has unmitigated access to
everything; unrestrained JavaScript can easily escalate it's own
priviledges. Right now, I only allow full system-wide superusers access to
persisting functions, due to this security concern. However, with JavaScript
with capability-based limits as in Caja or ADsafe, I could safely allow
functions to be persisted as long as they are properly limited in their
ability.
> May I forward this correspondence to e-lang
> <http://www.eros-os.org/mailman/listinfo/e-lang> and
> google-caja-discuss
> <http://groups.google.com/group/google-caja-discuss>? Thanks.
Yes, absolutely, consider my text public domain as well ;).
Thanks again,
Kris
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the e-lang
mailing list