On 2004, Jul 24, , at 19:05, Mark Miller wrote:
>[...] Several of us were distracted, in a major way, this
>week. More about that soon...
We were distracted by an invitation-only workshop, held at HP Labs, focused
on exploring future possibilities for Croquet.
http://chess.eecs.berkeley.edu/croquet/ is a start on a website resulting
from this workshop. The workshop was organized by Rick McGeer and attended
by about 30 people, including
* three of the main Croquet architects (David Smith, David Reed, and Andreas Raab),
* several other Croquet-ers (Mark McCahill, Julian Lombardi)
* and Squeakers (Dan Ingalls, Ted Keahler, Lex Spoon, Anthony Hannan, Ian Piumarta, Scott Wallace),
* several members of the e-lang community (Chip Morningstar, Kevin Reid, Ka-Ping Yee, Marc Stiegler, Alan Karp, Tyler Close, Dean Tribble, and myself),
* George Bosworth of Digitalk Smalltalk and .NET CLR fame,
* Robert Adams of Intel and PlanetLab,
* and Prof. Edward Lee of Berkeley.
* (and probably some others I forgot)
The Electric Communities and e-lang perspectives were represented well, and
played well with other perspectives that were presented. I think the
lessons from our perspectives were taken to heart, and their relevance to
the Croquet undertaking were clear. Actually, I think I'm way understating
the case, but I'll wait to see what others have to say.
In any case, I think it's fair to say that we have consensus on using
object-capability security as the underlying security mechanism, on top of
which Croquet's security architecture should be built. And that we have
consensus that "Threads are evil" -- that the conventional (shared memory
multithreading & fine-grained locking) paradigm of concurrency is
unworkable, and that instead, time should proceed according to a partial
causal order among events, where each event is the deterministic execution
of a sequential program to completion. (E and Croquet already have this
perspective in common, but with some interesting differences.)
I have asked the Croquet architects to evaluate the suitability of the
Kernel-E virtual machine definition as a proposed foundation on which
Croquet should be reconstructed. They are currently evaluating it. If
adopted, the plan would probably be to start by completing Dean's
E-on-Squeak effort in the short term, and do a more direct implementation of
Kernel-E on their virtual machine infrastructure in the long term.
At 04:05 PM 7/28/2004 Wednesday, Kevin Reid wrote:
>>(Note: the picture painted here doesn't yet cover the case where there are
>>potentially multiple authoritative presences. I now think I like Dean's
>>proposal for that better than Uni-Tea
>>http://www.erights.org/talks/uni-tea/index.html .
>
>I don't recall or never heard what Dean's proposal was.
In the Uni-Tea proposal, we map a Tea Party to an Unum, and make the
replication of authoritative presences be a generalization of presence
spread among vats. Dean suggests that, instead, we map a Tea Party to a
virtual vat, and implement fault tolerant replicated vats. Then, at the vat
level of abstraction, an individual Unum would still just have one
authoritative presence, permanently tied to its virtual vat of origin.
Rather than making the replication, consensus, and fault tolerance protocols
be Unum design choices, we should make these choices when instantiating a
fault-tolerant replicated vat. In Dean's proposal, it is especially clear
that you only do fault tolerant replication among sites mutually trusted to
try to run their replicas correctly, since that vat's private key would be
replicated at all those sites.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
[Message by Fred, reposted to e-lang, users@mozart, and squeak-e by MarkM.
I wanted to be sure y'all saw this. --MarkM]
Toby,
Three weeks ago Mark Miller, Jonathan Shapiro, Peter Van Roy and myself
submitted a paper for POPL05, that is to be regarded as a first step in the
direction you're pointing to. It does not yet deal with _automatic_ mapping
of policy specifications towards relied-upon abstractions of behavior, but
it contains a proposal for a formalism to express in which way relied-upon
("trusted") entities reduce their authority-providing behavior when
interacting with other entities, and to consequently examine the resulting
boundaries in authority propagation. We called it "Authority Reduction
Systems" in the paper, and we derived its mechanisms and features from an
analytical comparison between H.R.U. Protection Systems and Take-Grant Systems.
I consider your remark as (one of) the next step(s) to be done now:
1) build tools that proof the "safety properties" of an arbitrary
configuration that contains some entities of which (part of) their behavior
restrictions are known or relied upon.
2) build tools that propose the injection of reliable entities at strategic
places in a configuration, to assure a given set of "safety requirements"
for a given class of configurations.
I hope we will then also be able to translate arbitrary security paradigms
into such "classes of initial configurations", with a minimal set of
initial conditions, and reliable entities put at strategic places to enforce
the policy. ( I'm not sure I make myself clear, I suggest you read the paper
for more details)
I've just started working towards such a tool, using techniques from
constraint programming which are relatively new to me (all help is very
welcome!). I think it is possible to build a tool that can find the minimum
number of reliable entities to be injected, the minimum set of restrictions
each of them should respect, and the best places amongst the other agents to
install them, as to guarantee the requirements of an arbitrary security policy.
You can find our paper "Authority Reduction in Protection Systems" on the
MILOS project site:
http://renoir.info.ucl.ac.be/twiki/bin/view/INGI/MILOSProject
(last entry under the topic "Capability Theory")
All comments on the paper are very welcome on this mailing list.
I hope it will point you in the right direction.
cheers,
Fred.
-------------------
Fred Spiessens
UCL Louvain-la-Neuve Belgium
http://www.info.ucl.ac.be/people/fsp/fred.html
------------- you're invited to: -------------------------
the Second International Mozart/Oz Conference
(MOZ 2004)
Charleroi, Belgium, Oct. 7-8, 2004
http://www.cetic.be/moz2004
-------------------------------------------------------------
On Aug 11, 2004, at 3:22 AM, Toby Murray wrote:
>In my reading of literature regarding capability systems and implementations I'm yet to find any work that deals with the automatic mapping of an abstract policy specification (in whatever appropriate paradigm) to rules regarding capability propagation between entities, and trusted abstractions built over the base system. While it has recnetly been explicitly recognised in the literature (at least from my understanding) that trusted abstractions enforce security as well (and therefore are an embodiment of the policy) -- with the decisions regarding distribution of capabilities between entities being the other embodiment of policy -- it appears that we'll have to be able to build these abstractions and generate propagation rules automatically that can be enforced by trusted code, if capability systems are to become practical.
>Perhaps capability systems make this problem harder because they allow almost arbitrary security paradigms (in which any policy must be framed) to be mapped onto the base system. (eg. we can do RBAC or Bell-LaPadula if we want to build the right abstractions and come up with the right rules etc.) We have seen very small examples here and there (eg. indirection for temporal revocation, and the example used by Shapiro et. al to show that the *-property can be enforced), but all of these must be crafted by a human who "knows" that the abstraction and associated rules actuall embody and enforce the abstract policy.
>Has any work been done in this area and if so could someone point me in the right direction?
>
>Thanks,
>Toby
>
>--
>Toby Murray
>Software Engineer
>Advanced Computer Capabilities Unit
>Information Networks Division
>DSTO, Australia
>
>IMPORTANT: This e-mail remains the property of the Australian Defence
>Organisation and is subject to the jurisdiction of section 70 of the
>Crimes Act 1914. If you have received this e-mail in error, you are
>requested to contact the sender and delete the e-mail.
>
>_______________________________________________
>cap-talk mailing list
>cap-talk(a)mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk
_______________________________________________
cap-talk mailing list
cap-talk(a)mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
