[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

Bill Frantz frantz@communities.com
Fri, 02 Feb 2001 14:04:24 -0800


At 12:40 AM 2/2/01 GMT, David Wagner wrote:
>It may be that the possibility of even finer-grained protection domains
>than that can't hurt, and can only help -- it sounds likely.  I suspect my
>reaction is partially affected by my distrust in the ability of type-safe
>languages to provide a high enough level of assurance.  The lesson I
>draw from the Java experience is that, with today's technology, type-safe
>languages just don't provide the same level of assurance of isolation that
>is achievable with more traditional techniques (separate address spaces,
>MMU chips, RPC for communication between distrusting processes, etc.).
>But I want to say this: if I had a mechanism for imposing super-fine-grain
>security boundaries that I could trust, I would almost certainly feel
>very differently about the matter.

To some extent, the level of assurance you need depends on the threat.
Capability languages, such as E, provide enough assurance to protect a
programmers against their own mistakes; even while they aren't strong
enough to protect against hostile programmers.  Even running under a system
like Windows, they can make a real contribution.

The system I really like is a capability language running in a capability
OS.  E in EROS comes immediately to mind.

At 11:24 AM 2/2/01 -0700, Marc Stiegler wrote in response to David:
>>That's why
>> I'm asking these questions: Not because I have a special aversion
>> to E or to capabilities, but because I'd to understand what the
>> benefits are, where they're coming from, and whether it's possible
>> to reap partial benefits with a less radical change to the way I
>> program.  In other words, can I pay only some of the cost and get
>> some of the benefits back?
>
>I understand and fully sympathize with your goal. Getting to a better future
>through small evolutionary steps is always just better when it can be made
>to work.
>
>...
>
>These personal experiences plus the absorption of shared community
>experiences have consequently driven me, despite my natural inclinations, to
>accept another statement: To solve the security problems of today's world,
>we need a phase transition. And to cross the transition, you have to start
>over from the core.
>
>...
>
>Better, of course, would be to actually find an evolutionary way across the
>transition :-)

My own preference is to follow the kind of course Apple followed when they
introduced the PowerPC.  Lift up the old stuff and slide a new core
underneath it.

I think a lot of real world benefit would come from a Principle of Least
Authority (POLA), capability based, Unix system.  In this kind of system,
the shell would automatically give each command access to all the files
mentioned in the (expanded) command.  This functionality would make
something like:
  grep createAvatar `find . -name '*.java'`
run in a POLA environment.

The next step is to associate certain accesses with specific programs.  The
man  program needs access to the manual files, and can gain access thru
this mechanism.  The same applies to gcc and certain include directories,
as well as to writing a.out.

As a final mechanism, when a program tries to open a file not mentioned in
the command line or automatic list,  we can ask the user if access should
be permitted.