harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Macneale <mac4-harm...@theory.org>
Subject Re: Security
Date Mon, 04 Jul 2005 07:18:46 GMT


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

Mime
View raw message