Re: Runtime info flow in Java

[Christian Wettergren <cwe@it.kth.se>]

| At 7:06 AM 5/9/96, Christian Wettergren wrote:
| >Hi!
| >
| >I'm presenting my licentiate research proposal
| >next week, and I thought that some of you might
| >find it interesting. I'd like to find others
| >that are working with similar projects, to have
| >some people to discuss with.
| >
| >The actual proposal is available at
| >
| >     http://www.it.kth.se/~cwe/phd/licprop.ps
| 
| I began to look at your paper online but that works poorly for me. My
| printer does not handle A4 paper. PostScript seems inflexible in this
| regard. If it were available in 8.5 X 11 inch format you would have least
| one more reader.

I've uploaded a letter-formatted version of the paper as well now.
(Or I hope so at least, can't try it here since we only have A4 paper.)

I have also put the original FrameMaker document there, as well as 
a small presentation in PowerPoint about the topic. Take a look at
http://www.it.kth.se/~cwe/phd/ for more information.

| I am interested in your paper because you define the problem as we do.
| There are some who think that capability architectures are the solution.
| There is little information on how to solve these problems with
| capabilities. I am trying to find time to address some of these issues.
| 
| KeyKOS is a capability based operating system that is designed to solve a
| variety of security problems. There are some papers at
| <http://www.cis.upenn.edu/~KeyKOS> and
| <http://www.webcom.com/agorics/library.html>.

I've read briefly previously about KeyKOS, I believe it was in IEEE
Symp on Sec & Priv, or something like that.

I'll take a closer look at KeyKOS. It is interesting to find others
doing similar things, since it is quite hard to find previous work
in the area. (I've digged through Comm of ACM all the way back to
1969 for material. Sigh! :-))

| We find that Java as a language conforms well enough to capability
| principles even though not using the term. Some of the primordial classes
| do not conform and indeed it was there that the Princeton group found the
| problems that are most difficult to fix.

I have experiences from UNIX, and I would say that a large number of the
security problems in the daemons are due to the fact that the programmer
did not succeed in keeping data from different subjects separated. This is
today solved by ad hoc methods by the programmer, and the task is too
difficult.

One of the things I want to examine is how fast a subject's influence
is spreading through the program during execution. I'm worried that the
influence in general is not contained, and that one either has to have
a very intelligent compiler or have to rewrite most programs to take
advantage of the scheme. I hope to be able to straighten out this question
mark during the coming months.

/Christian