From: Christian Wettergren <cwe@it.kth.se>
Date: Tue, 28 May 1996 22:39:12 +0800
To: norm@netcom.com (Norman Hardy)
Subject: Re: Runtime info flow in Java
In-Reply-To: <adcc0ddc040210048873@DialupEudora>
Message-ID: <199605281015.MAA21153@piraya.electrum.kth.se>
MIME-Version: 1.0
Content-Type: text/plain



| 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