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

David Wagner daw@mozart.cs.berkeley.edu
3 Feb 2001 03:14:18 GMT


Marc Stiegler wrote:
>David Wagner wrote:
>> [...] 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"?

That's a fair question; I realize that I was a little ambiguous.
I intended to refer to a system where security relies on the language
to be type-safe.

As for the characteristics of a capability-secure system listed in
your E in a Walnut book, yes, they include a type-safety requirement.
They do also include requirements that I wouldn't lump under type-safety,
such as that the API be carefully designed.  Nonetheless, if I
understand properly, E seems to rely on type-safety for security
(it's part of the TCB, I think).  Is that right?

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

I guess you could say I'm worried about (1).  However, I think my
concern goes a little beyond just a general concern over the size
of the TCB (although that may be a goodly part of it); I'm worried
by the community's history of failure at building type-safe languages
with enough assurance that we can rely on the type-safety for security.

I'm not worried about (2).  (Should I be?)  It seems to me that, no
matter what language you use, no matter how you structure your system,
you have to be sure your OS can't be attacked through the interface
it exports to applications.  That's just part of the job of building
a good OS, and the fact that applications are using capabilities
doesn't make it any harder.  Right?

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

Yes, I accept that.  I'm also perfectly willing to believe that there
are some problems where there is no evolutionary solution.  (The question,
of course, is whether "security" is one of these.)

I guess, to be more precise, I'm looking for a slightly different
sort of evolutionary step.  I'm not focusing on evolution over time,
where you'd have to secure a legacy application; I'm happy to restrict
attention to asking how to build new systems that have to be secure.
Instead, I'd ideally like to know if there are any partial steps I can
take that don't pervade my whole programming environment (which I've
grown familiar with).  If I have to change my whole OS, programming
language, libraries, API's, and so on, I want to be fairly sure that
(1) I'll get the benefits I expect, and (2) the investment is unavoidable.