Ben Laurie wrote:
> So, it seems to me that when you say its easier to write secure code in
> Java than C what you really mean is that its easier to write code free
> of buffer overflows in Java than C.
> 
> I can't think of _any_ other interesting security properties that Java
> has and C lacks. Am I missing something?

It has generally been my experience that buffer overflows are not an
issue in java code. Not because indexes are checked automatically, but
more because the .length field is prevalently used. It is uncommon that
I see IndexOutOfBoundsExceptions being thrown in my code, or the code I
rely upon.

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

Furthermore, by using the java.security package and it's friends we can
be assured that our Java code is behaving correctly. If there is C code
in the JVM which opens and writes to files, then we must manually check
to see that the JVM has permission to do so. If the code is written in
Java, then the SecurityManager class to takes care of that with no
effort to the developer. This may be a double edged sword since
developers who think "The SecurityManger will catch my bugs" are going
to dig themselves into a hole. But it's better than the C model which is
non-existant.

Neil

Reply via email to