[E-Lang] Other languages with secure capabilities

[Seif Haridi]

Sorry I am not able to answer right now. But the implementation of Secure Mozart
and the design for the first version is almost ready. The implementation is
interesting
in fact. At the language level security overrides distribution behavior to
guarantee language
security. The language itself is secure. This means for example that an object
that have
migratory behavior becomes stationary if an attemp to access the object comes from

untrusted site.

We will come back with full report, but I am traveling next week, so please wait
for
a while.

--- Seif Haridi

"Mark S. Miller" wrote:

> At 01:13 AM Wednesday 5/9/01, Peter Van Roy wrote:
> >I agree completely.  In fact, we used the same argument when designing
> >the protocols to make Oz network transparent.  Objects in Oz are mobile
> >by default (object state moves to process using it).
>
> While it may be the same argument in a different context, I fear that this
> argument has led you to a security-incompatible solution.  Unless you mean
> something very different by "object", then among mutually suspicious nodes
> objects must by default be stationary.  Further, non-stationary objects should
> not be considered mobile, but replicable.  For both, money is a great example.
>
> Many people have misread the MintMaker example
> http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
> as involving non-stationary Purses.  Of course, our code doesn't work
> under such an assumption.  But it's an interesting exercise.  If you believe
> in distributed object-based capability security among mutually suspicious
> nodes, and you believe that these secure objects can be non-stationary, then
> try to write a MintMaker equivalent in which the Purse-equivalents move to
> the machine of the client holding the Purse.
>
> As to "mobile" vs "replicable", if you could truly implement an object,
> designatable by a capability, that could change its host, but have all
> designators know to go to the new host instead of the old one, then you
> could implement the Holy Grail of money protocols: A money without an
> issuer.  A dollar (or whatever) could just be a mobile object, the current
> owner of the dollar would be according to the current hosting machine, and
> the dollar would change hands by moving between machines.  If you instead
> concede that double spending cannot be prevented without a stationary
> issuer, then non-issuer-managed objects are stationary or replicable,
> but not mobile.
>
> >The assumption of mutually trusting nodes is not a profound one; it is
> >part of our current plans of progressively introducing implementation
> >security in Mozart.  The very first step is allowing encrypted
> >communication.  This handles the mutually trusting nodes case, which is
> >actually an important special case.
>
> You may be able to implement security incrementally, but I doubt you could
> architect security incrementally.  Is there anything to read about Oz's
> planned security architecture?
>
> >Well, I do enjoy the discussions on the E list, even though I can't read
> >them all in detail.  Seif Haridi can probably respond better to your question
> >than I.
>
> I look forward to it.
>
> >> Btw, to whom should I send an invitation to put Oz on the Capability
> >> Security WebRing?
> >
> >Send it to users@mozart-oz.org, the interested Mozart developers will
> >respond.
>
> Good.  Done.  Looking forward to seeing you folk on the ring!
>
>         Cheers,
>         --MarkM
>
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang