[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [E-Lang] Re: Call chain information
From:       Paul Snively <psnively () earthlink ! net>
Date:       2001-08-13 5:15:47
[Download RAW message or body]

Hi Robin!

My name's Paul Snively. In a previous life I was a game developer, first for
a little company named ICOM Simulations that did graphical adventure games
for the Macintosh and, later, other platforms (Déjà Vu, Uninvited,
Shadowgate, Déjà Vu II: Lost in Las Vegas) and, much later, for Activision
(Spycraft: The Great Game and Muppet Treasure Island were the ones I was
involved with).

Multiparticipant online environments are something of a passion of mine--I
used to spend a lot of time (FAR TOO MUCH time, to be honest) on Pavel
Curtis' LambdaMOO. I tried to be a programmer on LambdaMOO, but its system
of ownership, quota, and object creation was hopelessly broken and I gave
up. I still have what today would be called a MMORPG (Massively-Multiplayer
Online Role-Playing Game) rattling around in my head, and I, too, have
already settled on Oz for developing it. It's quite a ways off, though, but
that doesn't mean that I haven't given the architecture, and how I would
implement it in Oz, a great deal of thought--literally years' worth.

That's the brief background for my comments. I'm hoping that this will be
the beginning of an ongoing dialogue.

> So, I'm writing a MUD in Oz. This means that I have to assume that any
> given object in the MUD could have been written by an arbitrarily
> malicious person. But I still want to allow potentially destructive
> things to occur. 

Right. There's more to "security" in this kind of environment than simply
keeping "bad people" from doing "bad things." One participant may not trust
another, but may still wish to create/use objects that interact with object
created/used by the other in meaningful ways. This definitely calls for a
degree of subtlety and flexibility in the security architecture that's
infrequently found in real-world systems.

> Obviously, there needs to be some way to do access control, or something
> like it. The easiest way is for a method to somehow be told the
> identity of the calling object, but it needs to be in a non-forgeable
> fashion. 

Right again, but be careful about notions like "access control" and
"identity." Most systems built around such concepts have serious security
holes, failing to provide the level of cooperation among mutually-suspicious
principals that you seek and, in many cases, even allowing serious security
breaches (in fact, AFAIK, ALL systems built around "access control lists"
are seriously broken in the sense of suffering possibly severe security
breaches). An excellent problem description for software security can be
found <a href="http://www.erights.org/elib/capability/3parts.html">here</a>.

A somewhat more fleshed-out description of the problems, and the correct
approach to their solution, can be found <a
href="http://www.skyhunter.com/marcs/capabilityIntro/index.html">here</a>.

The best summary overview of capability security I've seen in one place
remains <a href="http://www.erights.org/elib/capability/ode/index.html">the
ode to the Granovetter Diagram</a>.

Another excellent reference regarding security at the programming language
level is <a href="http://fare.tunes.org/tmp/emergent/secureos.htm">A
Security Kernel Based on the Lambda Calculus</a>, which deals explicitly
with security in MUDs/MUSHes/MUSEs/MOOs.

> So, is there any way for me to get this sort of information already
> built into the language? Otherwise I'm either going to have to have a
> central mediator of method calls or use public key crypto, I think.

<a href="http://www.cap-lore.com/CapTheory/ConfusedDeputyM.html">This
description of the confused deputy problem</a> specifically addresses the
"central mediator" problem. The ode to the Granovetter Diagram, linked to
above, deals specifically with the analogues between capability security and
cryptography. Of course, if you wish to build a distributed system, you'll
need cryptography on the wire. <a href="http://www.erights.org">The E
programming language</a>, a capability-secure programming language, already
supports on-the-wire cryptography, and on-the-wire cryptography is, as I
understand it, coming in the not-too-distant future for Oz.

In any case, suffice it to say that Oz is well on its way to being a
capability-secure programming language (but see <a
href="http://www.mozart-oz.org/lists/oz-users/0861.html">this Oz users
mailing list thread</a> for some discussion about flaws in security thinking
in at least one of the Oz papers). No stack-crawling or establishing
"identities" of callers is necessary. The time to get this crucial aspect of
Oz right is now, and since you and I have extremely similar goals for our
use of Oz, perhaps we should ally and help ensure that this happens. :-)

> Thanks for your help!
> 
> -Robin 

I do hope this helps, and let's keep in touch,
Paul

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]