Ben Laurie wrote:
Neil Macneale wrote:
[snip]
Preventing buffer overflows is a commonly sighted advantage of java, but
there are other advantages as well. There is a common architecture for
signing and verification of code.
Woah. This doesn't provide security in any interesting sense. And PGP
signatures on C source are just as good.
As I've stated in another message in this thread, I am not interested in
a Java Vs. C argument. You are correct, signing C code is no different
than signing java code.
As far as verification of source, that is one facet of security.
Fraudulent packages are certainly a real world problem. When a trusting
user downloads a open source package and hits install, they are taking a
huge leap of faith. JVMs are put under a lot or pressure in this regard.
What is the point of running an applet, which is supposedly running in a
secure sandbox, if you can't trust the JVM?
My primary concern is this: When a person is looking for a JVM to use,
and they are equally open to Sun JVM and the Harmony JVM, it's a count
against harmony when they ask "How secure is it?" and the response is,
"Pretty good, we hope," they are going to go for the Sun JVM which
claims to be rock solid.
Companies can make statements like that (why, I'm not really sure, but
they do). Open Source Projects simply have reputation to build on. And
that reputation is only torn down when vulnerabilities are found and
exploited. So how do we prevent their existence from the get go?
I believe being an ASF project gives a vote of confidence right away
because Apache is highly respected in the open source community and
beyond. But that would quickly get eroded after a few cases of rooted
machines.
The two JVMs I have installed return
null when I attempt to get the signers of the String class. It would
seem reasonable to me to have a hard coded public key in Harmony so we
could verify the validity of the libs. These tools can also be used to
seal jars, thus assuring that when someone downloads and installs a
standard build of Harmony, they can be fairly certain that they didn't
get an image with a back door built in. (Note this brings up a separate
issue of having a SSL trusted host, but lets not go there yet.)
See above.
Furthermore, by using the java.security package and it's friends we can
be assured that our Java code is behaving correctly.
You can? How?
[snip]
>
> How hard is to write a wrapper for open() in C? Why is that different
> from using SecurityManager?
(I am hesitant to respond to this, for fear of a language argument, but
I will anyway). Say there is a developer who wants to add one single
feature to Harmony, and he codes it up and sends a patch to this list.
Chances are that person didn't read through all the other source code in
the tree and there is a good chance that the didn't read about the
harmony wrapper for fopen. So they use fopen, not knowing that
harmony_fopen is the proper way to do things. The C compiler will make
no complains about the use of the native fopen. (I concede, #defines and
creative use of shared libs can go a long way to fix things like this,
but they are not perfect).
With java.security, when you write a file the most common way to do so
is by creating a java.io.FileOutputStream. And that's secured by
java.security. So instead of the developer above needing to read through
lots of code to discover that fopen is a bad thing, they use the classes
they are familiar with and get the correct result. Furthermore, there is
no way to create a file without going through the SecuirtyManager
(assuming the JVM is implemented correctly, which requires people to
verify and is more my concern than this technical blather :-). The
language and the std lib does not allow it. Any attempt to circumvent
these checks by loading a native library are quickly negated because the
SecurityManager can prevent that too.
BTW, have you ever seen plash?
http://www.cs.jhu.edu/~seaborn/plash/plash.html
That's interesting. Running in that type of environment has merit.
Neil
