[1619] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Re: Java "security holes'

daemon@ATHENA.MIT.EDU (David M. Chess)
Wed Mar 13 15:14:30 1996

Date: Wed, 13 Mar 96 12:10:38 EST
From: "David M. Chess" <chess@watson.ibm.com>
To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu

Thanks for the reply!

> (except I don't think we'd claim it would outline "all" the
> security-relevant things - that is a big claim - )

A security model should list all the things that are officially
part of the security model.  There will always be other stuff
lying about (covert channels), but as they're discovered you
can incorporate them into the security model.

> What's really needed is an implementor's guide about do's and don'ts,
> for example, how to take advantage of Java to build secure
> applications, and what to look out for.

That's needed *after* a security model for the language and
the engine itself exists.  After the security-relevant
entities and attributes and knobs have been pinned down,
it'd be good to have guides for users and Java-writers,
to give them a task-oriented view of how to use it all.

But it requires work on the security model first.  A
guide for implementors on how to use the current informal
and incomplete and model-less set of "security features
that we happened to think of while designing the system"
would be, IMHO, just a stopgap...

DC

home help back first fref pref prev next nref lref last post