At 9:09 AM 5/24/96, Lucky Green wrote: ....

I walked away from your presentation of KeyKOS with the impression that a capability system to be secure it would have to be implemented at the OS level. Can you build a such a system on top of an insecure OS, as Java would have to do? .... I agree with everything that Bill Frantz said. I certainly didn't mean to imply that a system such as Java could not be secure.

I can't think about a whole system at once. We developed KeyKOS over a span of several years and we were able to convince the NCSC it had a firm security foundation. The NCSC convinced us to do some formal descriptions of our system to articulate some of our previously undescribed programming patterns. These said in a somewhat mathematical way how capabilities work. (Like you can't do something to zot unless you have a capability to zot. etc.) Object references in C++ and Java pretty much conform to these capability patterns. In Java you can get an object reference only when you create the object or some one passes it to you (or you get it thru a shared variable). In C++ you can also get an object reference by casting and other chicanery. None of these formalities seemed the least bit surprising. There was no deep mathematical insight here. It was merely restating the familiar in very different terms. The exercise did lead us over some old territory with new eyes and we saw some easily eliminated covert channels that we had been unaware of. We do not have a complete map between capabilities and Java. There are things about Java that we have not mapped to capabilities yet. For instance any piece of code in a Java program that can declare a reference to an object of classs Zot is also able to invoke any of the public constructors for Zot. This may be too strong an ability. (In KeyKos you could create a zot just in case you held the capability to the zot creator.) Perhaps you put all of the constructing code in static methods for Zot and make all constructors private. It is important that some code be able to construct Zot instances that other code is unable to construct. Java's security manager classes are not capability like. They seem to us too much like merely a series of plausible decisions for which we can see no general principles. Each decision makes sense but we have no feeling that they are complete. I suppose that the above sounds as if I am saying "Trust us. We know all about security.". Unless the end user is able to understand just what the lattitude that the applets in his machine have, he has no security. Java will not be secure until the security principles can be understood by the intelligent end-user. I think that you must make graphically explicit which agents in the computer have access to the phone. You may be keeping secrets because untrusted agents can't phone home, or because they can't see the secrets. Current user interface design is predicated on the idea that such issues should not concern the end user. I dearly wish that when some application in my Mac complains that it can't get the phone, there were a way for me to find out who was using the phone and take it away from him. I would also like to easily deny applications access to the phone. Even more I would like to explicitly grant phone access to an application just as I must plug my modem into the phone line before it can transmit bits from my house. In such a system I could begin to reason about where the secrets were going or why things didn't work. Access to the phone should be via a capability. The same goes for TCP connections, the ability to send a user data gram to a given IP address. Access to a random stream of bits should be via a capability. Access to a particular file or directory should be a capability. etc. etc. Everything should be a capability!!!