[cap-talk] Language-based safety - contest, cumulativereplies, is winning possible?

[Stiegler, Marc D]

> The above seems to suggest that there are as yet no 
> commercial interests 
> depending on the language based protections in E.  Is that true?

To the best of my knowledge, there are no commercial interests based on
these principles. With an open source download available, this is not
definitive, of course, but sadly indicative. 

 
> Regarding Squeak - are you referring to this Squeak:
> 
> http://www.squeak.org/
> 
> ?  If so I find it difficult to imagine the motivation for re 
> hosting E on 
> Squeak.  Is there somewhere I can read about the motivation?

The motivation is fairly simple, summed up in 3 sentence fragments:
Speed. More Speed. Vastly More Speed.


> However, Mark Miller says, "E-on-Java's security depends no 
> more on Java's 
> security than an E-on-C's implementation would depend on C's."
> 
> Is there a fine point that I'm missing here or can we 
> consider anything 
> that one can access of Java *through* E as fair game?

Not everything in Java conveys authority. Holding the ReadStream class
does you no interesting good, only getting a ReadStream object that is
on something interesting has authority, (so a readstream on something
like a file, or on a string that is part of some other object's private
area). All <unsafe> classes and objects are fair game, however.

> >I can understand how to attack a program which makes certain 
> security 
> >claims, but a language is a pretty vague target.  Are the 
> claims things 
> >like, you can only access an object if you have a pointer to it?

You can say this slightly more precisely, "you can only access an object
if you are explicitly handed the pointer by some other object, or if you
are the creator of the object, or if you are handed the pointer as a
part of your initial conditions". If you get that pointer any other way,
it's a breach, though we still have to discuss whether it's an
implementation or model breach.

> Would it suffice to just say to "break the caplet security 
> model" would 
> constitute meeting the requirements for winning the contest 
> or perhaps 
> there needs to be some sort of list of just what that would 
> mean (e.g. the 
> above two examples and perhaps many more)?

That would work too. I proposed using a simple framework with a 3-line
program, rather than the CapDesk caplet framework, because it is easier
to work with, and is not exposed to possible implementation bugs in
CapDesk. Understand that the caplet security model only exists to the
extent that CapDesk implements one. On the other hand, CapDesk is small
enough, and has been reviewed by David and Dean harshly enough, so that
it is not a bad choice of environment, though it is still more
complicated than the 3-line framework I suggested in earlier email.


> Still, the question of implementation or model comes up.  Is it even 
> possible in principle to breach the model?  For example, many 
> years ago I 
> felt I had breached the security model for the Burroughs 
> computers when I 
> was able to save on disk/tape a program that would execute arbitrary 
> machine code.  At that point no amount of tightening of the systems 
> security mechanisms would help it.  Only destroying all user 
> executables 
> would suffice - an economically untenable proposition at that time.

I cannot imagine an attack that could breach the model. But that could
just be a demonstration that I haven't been able to look at the problem
with fresh eyes for 7 years. I concede I can't figure out a solid way to
draw the line between an implementation breach and a model breach. Some
breaches obviously fall into the category of being implementation
breaches, I think, because they can be fixed with a one-line code
change. Many of the breaches David and Dean found fell into this
category, though a couple were harder to fix than just one line. 

An economic argument for the difference between model and implementation
breaches isn't very satisfying, particularly if the question is whether
language based security is possible in principle. In a Burroughs-like
analogy, there could be a breach that would only take one line of code
to fix, but if there were a million programs in the world that depended
on that line of code to operate in the current manner, it might still be
economically unfeasible to fix it. Is that really a model breach? 

On the flip side, Java is an interesting example to ponder: as we have
discussed, Java is 90% of the way to being a capability language.
JavaSoft could pay markm a million dollars and ship a Joe-E verifier
pretty quick, all 100% Java, and truthfully say they had a capability
secure version of Java. Very few new lines of code would be involved--an
itty bitty fraction of the total number of lines of code now in Java. Of
course, it would break absolutely every program ever written in Java.
Would one say that Java was suffering from a set of implementation bugs
prior to integrating JoeE, or was the model defective? I think the clear
indicator that it was a defect in the Java security model would be the
fact that, in Joe-E, the entire existing Java security module would be
discarded. But Java is close enough to capabilities that the line
between model and implementation is a little gray.

Looking for avenues of attack on the model, let us consider some of the
classical criticisms of capabilities that have been made, and see if any
of them can make sense. For example: an interesting criticism is still
the claim that you can't do revocation. The revocable forwarder (and the
caretaker pattern in Paradigm Regained) are not complete proofs that
revocation is viable. You need a membrane to really revoke the world. No
one has looked really hard at a membrane in E to see whether there is a
general way of bypassing them. As it happens, I recently wrote 2 simple
membranes for a class on E I am teaching; if you could find breaches in
them, and we couldn't find a way to fix the breaches, you'd have nailed
E's hide to a wall. I don't think you have the tiniest chance of
creating a model-level breach of an E membrane, but then, that is why
there's a prize :-)

--marcs