[E-Lang] Re: Old Security Myths Continue to Mislead

[Bill Frantz]

At 9:23 AM -0700 8/6/01, Marc Stiegler wrote:
>> Hmm. This strongly suggests to me that there is an important difference
>> between OO and capability-based programming that I have not yet discovered
>> how to articulate clearly...
>
>3) I hypothesize that one major reason Java code translates poorly to
>capability systems is that the assumption of ambient authority is so
>ubitquitous. It would be interesting for a grad student somewhere to walk
>through a substantive Java system to see what percentage of major modules
>assume ambient authority, I'd guess it is close to 100%. Believe me when I
>say, unless you have written a few emakers, you have no idea how much
>ambient authority you unconsciously assume when you are writing Java code
>(well, the EROS and KeyKos guys may have an idea. But even for Electric
>Communities, most of the coders could assume all the ambient local-platform
>authority they could eat :-)

I think this point is the crux of the issue.  I came to OO programing thru
KeyKOS, which means my first OO language was Assembler.  I developed the
habit of not having any authority without a path, and specific code to pass
it.  The level of coding involved was much greater that involved in rapid
prototyping systems, for example Unix and C.  (Rapid prototyping systems
would be much less dangerous if the resulting code was bomb proof.  Java,
with its automatically checked strings and arrays, does much better in this
regard than C.)

When I started working in Java, I was surprised with how many patterns in
the library used techniques we had avoided in KeyKOS because of their
impact on security.  For example, String interning implies a shared
variable which would show up as a hole in a KeyKOS factory.  A KeyKOS
version of interning would be a "no hole" factory the yield of which would
only be shared between mutually trusting objects.

The java.io.File class gives access to all of the user's directory
(actually access is much broader), a thought which horrified us with its
implications for Trojan horse mischief.  The pattern we used was much more
like having the shell pass open file handles to the program it invoked.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA