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

[Karp, Alan]

I'm not so sure about being able to slide a new core in underneath an
existing system.  When developing e-speak, we realized we had no chance of
adoption if we could not support legacy applications.  Our approach was to
provide wrappers.  For example, one of our engineers e-speak enabled SAP in
under 2 days.  We knew that such apps wouldn't get the full benefits of
being natively e-speak aware.  

The wrapped apps did benefit in the areas of naming, location independence,
discoverability, and manageability.  However, we found it difficult to add
very much to their security.  The problem, we ultimately realized, was that
the underlying security policies were not expressed in capability terms.  We
couldn't see how to substantially improve the security without doing a great
deal of work on the wrapper.  Since a key part of our value proposition is
the simplicity of writing wrappers, we made the (marketing) decision not to
even try.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Bill Frantz [mailto:frantz@communities.com]
> Sent: Friday, February 02, 2001 2:04 PM
> To: daw@cs.berkeley.edu; e-lang@eros-os.org
> Subject: Re: [E-Lang] Java 2 "Security" (was: Re:
> WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
> 
> 
> 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.
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>