Re: Runtime info flow in Java

[norm@netcom.com (Norman Hardy)]

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!!!