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

Marc Stiegler marcs@skyhunter.com
Fri, 2 Feb 2001 11:24:40 -0700


> As for the rest, I understand the purpose and value of combining
> designation and authority, and I agree that it seems to be a nice
> benefit.  I'd like to understand, though, whether I can obtain some
> of this benefit without requiring a radical change to a new type-safe
> programming language, operating system, and so on ... especially the
> language part, because I'm a little skeptical on whether type-safe
> languages can provide the level of assurance I'd like.

When you say "type-safe", do you mean something like E, which I refer to as
"capability-secure"? A list of the characteristics for being
capability-secure is included in the Secure Distributed Programming chapter
introduction in the book E in a Walnut if that would be helpful.

Having the capability security embedded in the language has the following
weaknesses:

1) You have an uncomfortably large TCB
2) the underlying operating system can still be attacked by software written
in a non-secure language (i.e., the TCB still winds up including all the
software ever executed on the system that was written in a non-capability
language).

Are these the assurance failures to which you refer? Or is there some other
issue you have with putting the security in the language?

>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.

Having lived with this community of capability-enthusiasts for many years, a
community of people who have struggled from time to time to find a more
evolutionary approach, and now having personally in the  last 2 years
accumulated some real experience with Java Security Managers, Unix ACLs, and
firewalls, while at the same time accumulating experience with E, I have
become convinced of the following statement: If you get the security wrong
at the core, and then try to tack security on at the end when you find you
have a security problem, you can never get it right. You can make it
complicated enough so that you yourself don't know of any security holes,
but by that time it is also so complicated that you can't tell if there are
any security holes that you can't find in that complexity. The really
practical consequence is this: you never sleep well at night :-) The less
often practical consequence is this: someone gets control of your computers
and prints your confidential info in the Merc :-)

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.

None of this is intended to prove that I am right, of course. It is just the
story of my journey, and if one day you notice that you are on the same
journey, perhaps you will then be able to leap the last few steps more
quickly knowing where the path leads :-)

Better, of course, would be to actually find an evolutionary way across the
transition :-)


--marcs