[E-Lang] Other languages with secure capabilities

Mark S. Miller markm@caplet.com
Sat, 12 May 2001 13:54:14 -0700

At 01:07 PM Friday 5/11/01, Pericles Akritides wrote:
>The context is the enforcement of the language rules and the ``real truth''
>of Seif's statement is whether you trust a remote site's virtual
>machine to enforce the language rules or not. All other notions of trust are
>handled by the rules of the language, such as controlled visibility,
>unforgeable references and Oz-names/chunks (the latter is an Oz specific
>idiom for rights amplification).

Let me suggest some terminology we've found clarifying.

For the longest time, we tried to talk about the machine to machine issue in 
terms of "trust", with some success (of which the most relevant is 
) and some confusion.  Recently, when I made more precise what I meant when 
I said "trust" in this context, Ben Laurie suggested the word "rely", which 
has worked great.

We define "A relies on B" to mean "A's correctness depends on B's correctness".

This is similar in meaning to MarcS's much more vivid "A is at the mercy of B".

The conventional notion of a subject-dependent TCB, for subject A, is just 
the transitive closure of all the things A relies on.

In security analysis, one often speaks informally of "The TCB".  When a 
concept won't go away, even when a bunch of people trying to be precise keep 
trying to avoid the concept, perhaps there actually is an important concept 
in there struggling to be made precise.  Given an aggregation of 
computational entities called "a platform", we define the UTCB (Universal 
TCB) to be the minimal collection which is the intersection of the TCBs of 
all entities on that platform not in the UTCB.  This normally includes the 
CPU, disk drive, OS, bootstrap logic, and all the people with physical 
access to the machine.  I think this captures well the intuition behind the 
phrase "The TCB".

If we define our platform more narrowly, we get a larger intersection.  For 
the objects running in an E vat, the vat implementation is part of the UTCB 
in addition to the normal UTCB.  An object is obviously at the mercy of the 
correctness of the object system it's implemented in.

Now back to your issues.  If VatA relies on VatB, then to the objects on 
VatA, VatB is now in their UTCB as well.  If VatB also relies on VatA, then 
they have formed one joint UTCB with a distributed implementation, and both 
sets of objects now have a shared (larger) set of vulnerabilities.

This is fine.  I don't have the objections to this you might expect me to.  
 From a security perspective, this isn't appreciably different than 
engineering a single machine secure language.  But this is still great!  The 
number of well designed single machine secure languages can still be counted 
on two hands.

But before paying the price of postponing the issues of decentralized 
security, where no one party is universally trusted, please examine well 
whether what you get in exchange is worth the cost.  Should you commit 
yourself to decentralized security as the normal case, as we have, I suspect 
you will find elegant solutions to the performance issues you are concerned 
about, consistent with the other constraints.  In particular, reading 
between the lines, I suspect that what you really need is the Unum pattern 
invented by Chip Morningstar.

Whereas, if you postpone facing the general problem to long, you will 
probably find yourself continuing to postpone it.

>In the context of virtual machines enforcing language rules, you
>either trust another site or not. Perhaps we should be more careful
>with our terminology:)

In particular, the "you" above is more dangerous than the "trust".  Who 
trusts?  Is it virtual machine A that relies on virtual machine B, or is it 
certain objects running on virtual machine A that rely on virtual machine B? 
The latter is a step in the right direction.

>In Mozart as it is now, the case is always the exact opposite, sites
>assume that other sites will enforce the rules of the language. From
>a security point of view this is, well, bad. From a performance
>point of view however, this assumption has (non-negligible?) effects
>on the performance of the system. From the Oz transparent distributed
>programming point of view, performance is important too because we don't
>want people to be forced occasionally to go back to using explicit
>message passing for performance reasons (neither for security reasons
>of course... that's what we are trying to improve now).
>A considerable amount of engineering has gone into Mozart based on this
>assumption. It is our opinion that security* does not require
>incompatible modifications in Mozart. Limiting the current eager copying
>strategies is enough and is always possible to do. Of course, other issues
>such as secure communication and unforgeable references, are completely
>orthogonal to distribution semantics.
>* We are referring to implementation security, the language is already
>secure as long as the adversary stays within the boundaries of the
>language. Implementation security is an inevitable step towards becoming
>less academic:) the features you find contradictory in the current
>(insecure) implementation can be simply suppressed when implementation
>security is required by the application.

I can't imagine things will turn out as orthogonally in practice as they 
seem to in theory.  The decision about where to locate an object is 
non-transparent on grounds besides security and performance -- most 
especially, behavior under partition.  It's hard to imagine the force of 
this until you experience it.

I encourage you to try facing the full problem first.  Then if you want to 
optimize for special cases, like mutually relying virtual machines, I 
recommend you do that after you understand the general case.

>> On a more detailed level, if a site is truly untrusted, it should never
>> have acquired the authority to talk to the object in the first place,
>> much less cause it to move to another machine. For the truly untrusted
>> site to talk to the object means a security breach has already occurred.
>Of course this is true, we hope we have identified what was meant by
>untrusted in that context:)

A good example of the clarity of "rely" vs the confusion caused by "trust".