[E-Lang] E FAQ

[Marc Stiegler]

At this point, I have to ask the question, for which audience is the FAQ
designed? Is it designed for people with a taste for "academic" answers,
such as Jonathan's which discusses the history of security policy research,
or is it for what I would consider a wider audience more interested in a
sound bite about what the practical day-to-day issue is? I believe that FAQs
are generally intended more for wider audiences interested in sound bites
(with links to serious discussions of course: here in the world of the Web,
the chance to link sound bites to better explanations makes them less
criminal, even legitimate).

I have spent the last year thinking about sound bites about what is so wrong
with Java security that you have to discard it rather than enhancing it.
Here is the best bite I have figured out so far, which is based on Steven's
observation about awkwardness. Here are the 3 points (which makes it still
not quite a sound bite, but pretty close :-):

--by default, Java security comes in 2 flavors: so restricted that you can't
do anything useful (with an applet in a sandbox), and so wide open that it
is just as dangerous for trojans and viruses as anything else (with Java
applications).
--Java has a great many other security settings that are possible...but they
are so difficult to use that in practice no one ever uses them. (Personally,
I have never ever seen anyone use any of the other settings for a real
application, though surely somewhere someone has done so).
--Any security system so difficult no one uses it is hardly better than no
security system at all. Indeed, it can be worse, by projecting an image of
security that isn't there.

This overlong sound bite may be taken by JavaSoft as hostile, but it has the
unfortunate characteristic of being true. One cannot describe a flaw in a
system without sounding hostile to the developers and backers of that system
(indeed, in my experience, developers and backers of a system get angry if
your glowing praise is simply less effusive than they require from their
"friends"). Truthfully, when I read the original, it didn't sound all that
hostile to me.  I'd recommend removing the remark, "pervasive inattention",
which isn't actually true BTW, and the opening sentence about Sun's claims
which does set them up for a fall, but the rest is just a series of true
statements, some positive, some negative.

--marcs


----- Original Message -----
From: "Jonathan S. Shapiro" <shap@eros-os.org>
To: <e-lang@mail.eros-os.org>; "Steven J. Owens" <puffmail@darksleep.com>
Sent: Monday, October 08, 2001 6:17 PM
Subject: Re: [E-Lang] E FAQ


> I agree in spirit with what Steven Owens has suggested, and his wording is
> certainly less inflammatory than the original.
>
> That said, there is something his proposed replacement gets wrong, and I
> think we should consider how we might correct it. The particular words I
> disagree with are:
>
> > However, java's general security mechanism -
> > the sandbox, the java security manager and security policy - is
> > complicated and awkward to use.
>
> The problem is much worse than a matter of mere awkwardness. The
awkwardness
> is certainly real, and definitely a problem, but this should be a
secondary
> point in the paragraph. An important statement to make is something like
the
> following:
>
>
> Java's general security tools - the sandbox and the Java security
manager -
> are known to have a number of design flaws. Equally important, they are
not
> backed by any rigorous security model that would give us any basis for
> confidence in either their comprehensiveness or their correctness. Even if
> the implementation were completely free of design flaws and bugs, there is
> no reason to believe *in principle* that the Java security model for
> applications works. It has been repeatedly shown in security policy
research
> that security policies are easy to state and security mechanisms easy to
> build, but successfully enforcing the desired policies using the available
> mechanisms is unusual. Designing mechanisms that are flexible, composable,
> and effective is known (both practically and mathematically) to be
> exceptionally difficult. Until the claims made about Java's security
> mechanisms (or indeed, *any* security mechanism in *any* language or
system)
> are substantiated with public, rigorous verifications, these claims should
> be treated as unproven assertions and treated with considerable
skepticism.
>
> There are quite a number of basic security flaws in the Java runtime
library
> that can be fixed only by violating backwards compatibility. There are
also
> flaws in the core object specifications (every object has a mutex). Given
> that these flaws are known, and that fixing them would break most existing
> Java programs and libraries, we are skeptical that the Java environment
will
> ever come to provide meaningful protections between two applications
running
> in the same virtual machine.
>
> That being said, it is important to recognize the importance and value of
> safe languages. Java is in many regards quite a good application language,
> and the ability to run programs in distinct JVMs really does provide a
> degree of isolation that is not readily available in most language runtime
> environments. For many of the important Java target applications the
runtime
> startup overhead of "one program, one JVM" is prohibitive, which may be
why
> this issue has not received much promotion by Javasoft.
>
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>