Re: Runtime info flow in Java

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

| 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?
| [....]
| 
| 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.

First of all I'm concentrating on programs that deals with data input 
from many different subjects. There is a problem in trying to separate 
the influence of these different subjects from each other. What resources 
should the process be allowed to access? If it is too little, nothing 
useful can be done. If it is too much, you run a risk of compromise.

I try to achieve my goals in a somewhat different way than in a traditional
capabilities system. Much, if not most, of the security work make the 
assumption that the program can do anything, and that the OS doesn't 
know squat about what the program does from a security point of view. 
This clearly doesn't work anymore, at least in my view.

What I try to achieve is that one doesn't have to trust the program anymore.
The program is compiled with a special compiler that inserts an extra
"guarding" program in parallell with the original program. I call this the
"shadow code", since it shadows the original program's execution.

All data inputs to the process have a subject identity to them. The shadow
code keeps track of how these identities flow through the variables and the
execution path as the program is executed. Suppose we're calculating 
c := a + b, then the subject set of 'c' is the union of the subject sets of
'a' and 'b'; sset[c] := sset[a] U sset[b].  Subject sets appear, instead of
plain subjects, as you can see. This is a piece of shadow code that is
executed just before the original statement is executed. You have to
take care of the execution path as well for conditionals as well.

The subject sets are presented to the OS by the shadow code when the program
does a system call. These subject sets are now used to do *detailed* access
control for the *specific* system call. This (hopefully) solves the problem
of giving too much/too little access, since this decision now can be based
on the precise subject sets presented.

You can find a discussion on this in a power point presentation at
http://www.it.kth.se/~cwe/phd/licpres.ppt. Take a look at 
http://www.it.kth.se/~cwe for more info. Comments are most welcome!

/Christian