You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Neil Macneale <ma...@theory.org> on 2005/07/01 08:14:52 UTC
Security
Hello All-
I've been lurking for awhile and I think the significant discussion
about security in the Harmony JVM has been missing. Considering such
ideas as hot compiling code and making it executable sets off big alarm
bells in my head.
One huge pitfall in many software projects is putting off security until
later. Auditing of code becomes much more difficult as the code base
become large. Furthermore, as code grows old, people forget how it works.
Somehow the java gods have convinced the world that java is secure. But
that all relies on a the JVM executing as documented and with no
security holes of it's own. The number of ways in which a JVM could open
security vulnerabilities in a system is enormous, and this is amplified
by the fact that the language it self has a security model which is
fairly complex.
One of the reasons I am in favor of implementing as much of the JVM in
Java is that I think it is easier to write secure code in Java than in
C/C++. A small core in C/C++ would be reasonable, but from a reviewers
standpoint it is more difficult to guarantee that a piece of C code is
secure. Generally speaking, of course.
I'd be happy to read people's code and look for bugs, and I may end up
doing this just for yucks. Are other people concerned about this?
Thoughts, comments?
Cheers,
Neil
Re: Security
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Joel Neely:
> Typed, constrained object references vs. untyped, unconstrained
> pointers.
Yes, but at some point in the compilation process, you have to flatten
"safe" object references to "unsafe" machine addresses. You can defer
this to the last instant with typed assembly language, but I don't
think this implementation technique is common.
Or are you talking about the JVM/JIT compiler implementation language?
I think it has less impact on the security of the system than the
overall design choices (for example, do you want to guard against
unsoundness of the Java type system?).
Re: Security
Posted by Joel Neely <jo...@gmail.com>.
Re "Cast? Why do you want to do that?" one might respond with cases such as
- variant types,
- code to implement a container/collection with arbitrary payloads, or
- because I want to do something naughty.
OK, maybe my one-liner was a bit cryptic (mea culpa). The
less-abbreviated version reads more as the following:
The underlying conceptual model for C is computer hardware. For
example, a pointer "is" a memory address, and it is very easy to
mis-use such things in a way that corrupts data, provides meaningless
results, etc.
The underlying conceptual model for Java is ... Java objects, (mostly)
without regard for the physical environment in which the object may be
found at a given time. Both the notation and the run-time behavior
assist in maintaining that model.
This thread began with Neil's post urging that security be an early
consideration rather than an afterthought. To me, security has (at
least) two aspects:
- helping a well-intentioned person avoid doing Bad Things, and
- preventing an ill-intentioned person from doing Bad Things.
As C is a general-purpose programming language, one CAN use C in a way
to implement any concept that exists in any other language--although
the form of expression may vary quite dramatically in readability! ;-)
However, implementing nice concepts (and avoiding Bad Things) in C
often requires that one code to certain conventions and
"gentleperson's agreements" which are at a conceptual layer outside
what the language itself specifies or requires.
So, when I said that a pointer "is" a memory address, I didn't mean
that a well-intentioned person could ONLY think of it in that way
(although that was still the common explanation, the last time I
looked at beginning C materials). I meant that it is trivially easy
for a programmer (either through ignorance or malice) to access/modify
an arbitrary chunk of bits (at least within one's own process space)
in a way that makes Bad Things happen sooner or later, and in a way
that can be highly difficult to track down. The very fact that there's
such a thriving market for development tools to detect memory leaks
and other kinds of pointer abuse (deliberate or accidential is beside
the point) is an indication that this is a problem.
The alternative to spending lots of energy on detection and
remediation of certain kinds of problems/defects is to spend a little
energy up front to prevent those problems/defects from occurring to
begin with.
-jn-
On 7/4/05, Ben Laurie <be...@algroup.co.uk> wrote:
> Geir Magnusson Jr. wrote:
> >
> > On Jul 4, 2005, at 4:00 AM, Ben Laurie wrote:
> >
> >> Geir Magnusson Jr. wrote:
> >>
> >>> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
> >>>
> >>>> Joel Neely wrote:
> >>>>
> >>>>
> >>>>> Typed, constrained object references vs. untyped, unconstrained
> >>>>> pointers.
> >>>>>
> >>>>>
> >>>>
> >>>> C has typed pointers.
> >>>>
> >>> How are they really typed? In Java, I'll get a runtime exception
> >>> when I mis-cast... In C, IIRC, I get long hours of debugging...
> >>>
> >>
> >> Cast? Why do you want to do that?
> >
> >
> > I'll take this as a straight question, although I can actually hear you
> > saying it and I'm suspicious :)
> >
> > I actually never understood why I do it other than for readability,
> > because I do think that the runtime can figure it out.
> >
> > There's a legitimate use when upcasting to a superclass.
> >
> > public class Bar {
> > }
> >
> > public class Foo extends Bar {
> > }
> >
> > Foo f = new Foo();
> >
> > Bar b = (Bar) foo;
>
> I meant in C (which doesn't have superclasses).
>
> --
> >>>ApacheCon Europe<<< http://www.apachecon.com/
>
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
--
my morning coffee
middle-aged american
tea ceremony
Re: Security
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 4, 2005, at 9:17 AM, Ben Laurie wrote:
> Geir Magnusson Jr. wrote:
>
>> On Jul 4, 2005, at 4:00 AM, Ben Laurie wrote:
>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>
>>>> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>>>>
>>>>
>>>>> Joel Neely wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Typed, constrained object references vs. untyped,
>>>>>> unconstrained pointers.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> C has typed pointers.
>>>>>
>>>>>
>>>> How are they really typed? In Java, I'll get a runtime
>>>> exception when I mis-cast... In C, IIRC, I get long hours of
>>>> debugging...
>>>>
>>>>
>>>
>>> Cast? Why do you want to do that?
>>>
>> I'll take this as a straight question, although I can actually
>> hear you saying it and I'm suspicious :)
>> I actually never understood why I do it other than for
>> readability, because I do think that the runtime can figure it out.
>> There's a legitimate use when upcasting to a superclass.
>> public class Bar {
>> }
>> public class Foo extends Bar {
>> }
>> Foo f = new Foo();
>> Bar b = (Bar) foo;
>>
>
> I meant in C (which doesn't have superclasses).
And someone pointed out that I was wrong too, because I was just
waking up and didn't have coffee... Of course you don't need the
cast in my case.
I guess I was asking how pointers are typed in C...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Security
Posted by Robin Garner <Ro...@anu.edu.au>.
> >>> How are they really typed? In Java, I'll get a runtime exception
> >>> when I mis-cast... In C, IIRC, I get long hours of debugging...
> >>>
> >>
> >> Cast? Why do you want to do that?
> >
> I meant in C (which doesn't have superclasses).
>
Ever done a 'malloc' ? :)
Re: Security
Posted by Ben Laurie <be...@algroup.co.uk>.
Geir Magnusson Jr. wrote:
>
> On Jul 4, 2005, at 4:00 AM, Ben Laurie wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>>>
>>>> Joel Neely wrote:
>>>>
>>>>
>>>>> Typed, constrained object references vs. untyped, unconstrained
>>>>> pointers.
>>>>>
>>>>>
>>>>
>>>> C has typed pointers.
>>>>
>>> How are they really typed? In Java, I'll get a runtime exception
>>> when I mis-cast... In C, IIRC, I get long hours of debugging...
>>>
>>
>> Cast? Why do you want to do that?
>
>
> I'll take this as a straight question, although I can actually hear you
> saying it and I'm suspicious :)
>
> I actually never understood why I do it other than for readability,
> because I do think that the runtime can figure it out.
>
> There's a legitimate use when upcasting to a superclass.
>
> public class Bar {
> }
>
> public class Foo extends Bar {
> }
>
> Foo f = new Foo();
>
> Bar b = (Bar) foo;
I meant in C (which doesn't have superclasses).
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Security
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 4, 2005, at 4:00 AM, Ben Laurie wrote:
> Geir Magnusson Jr. wrote:
>
>> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>>
>>> Joel Neely wrote:
>>>
>>>
>>>> Typed, constrained object references vs. untyped, unconstrained
>>>> pointers.
>>>>
>>>>
>>>
>>> C has typed pointers.
>>>
>> How are they really typed? In Java, I'll get a runtime exception
>> when I mis-cast... In C, IIRC, I get long hours of debugging...
>>
>
> Cast? Why do you want to do that?
I'll take this as a straight question, although I can actually hear
you saying it and I'm suspicious :)
I actually never understood why I do it other than for readability,
because I do think that the runtime can figure it out.
There's a legitimate use when upcasting to a superclass.
public class Bar {
}
public class Foo extends Bar {
}
Foo f = new Foo();
Bar b = (Bar) foo;
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Security
Posted by Ben Laurie <be...@algroup.co.uk>.
Geir Magnusson Jr. wrote:
>
> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>
>> Joel Neely wrote:
>>
>>> Typed, constrained object references vs. untyped, unconstrained
>>> pointers.
>>>
>>
>> C has typed pointers.
>
>
> How are they really typed? In Java, I'll get a runtime exception when
> I mis-cast... In C, IIRC, I get long hours of debugging...
Cast? Why do you want to do that?
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Security
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Java can offer true sandboxing, while with C no library wrapping can
stop you from doing syscalls.
On 7/3/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>
> > Joel Neely wrote:
> >
> >> Typed, constrained object references vs. untyped, unconstrained
> >> pointers.
> >>
> >
> > C has typed pointers.
>
> How are they really typed? In Java, I'll get a runtime exception
> when I mis-cast... In C, IIRC, I get long hours of debugging...
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Security
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
> Joel Neely wrote:
>
>> Typed, constrained object references vs. untyped, unconstrained
>> pointers.
>>
>
> C has typed pointers.
How are they really typed? In Java, I'll get a runtime exception
when I mis-cast... In C, IIRC, I get long hours of debugging...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Security
Posted by Ben Laurie <be...@algroup.co.uk>.
Joel Neely wrote:
> Typed, constrained object references vs. untyped, unconstrained pointers.
C has typed pointers.
Unconstrained == buffer overflows, so I've already conceded that one.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Security
Posted by Joel Neely <jo...@gmail.com>.
Typed, constrained object references vs. untyped, unconstrained pointers.
-jn-
On 7/1/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
> I can't think of _any_ other interesting security properties that Java
> has and C lacks. Am I missing something?
>
--
my morning coffee
middle-aged american
tea ceremony
Re: Security
Posted by Florian Weimer <fw...@deneb.enyo.de>.
* Ben Laurie:
> 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?
Memory management bugs soemtimes result in security bugs as well.
But with respect to JVM security, I don't think such trivialities are
important. Writing a robust verifier/optimizer/native code generator
combination is difficult in any programming language (especially if
your design is somewhat flawed from a security POV 8-).
Re: Security
Posted by Neil Macneale <ma...@theory.org>.
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
Re: Security
Posted by Ben Laurie <be...@algroup.co.uk>.
Neil Macneale wrote:
>
> 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.
Woah. This doesn't provide security in any interesting sense. And PGP
signatures on C source are just as good.
> 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?
> 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.
How hard is to write a wrapper for open() in C? Why is that different
from using SecurityManager?
BTW, have you ever seen plash?
http://www.cs.jhu.edu/~seaborn/plash/plash.html
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Security
Posted by Neil Macneale <ma...@theory.org>.
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
Re: Security
Posted by Neil Macneale <ma...@theory.org>.
Tom Tromey wrote:
>>"Ben" == Ben Laurie <be...@algroup.co.uk> writes:
> Ben> I can't think of _any_ other interesting security properties that Java
> Ben> has and C lacks. Am I missing something?
>
> Probably not. At some point any VM has to do untrusted things. There
> may be reasons that this "window" is bigger or smaller, and smaller is
> probably preferable, but it doesn't seem to me to be a necessary
> consequence of the implementation language.
>
> That said, it does make sense to think not only about how to implement
> security, but also how to verify it, and likewise how to ensure the VM
> remains secure in the face of a lot of mutation.
This is actually more along the lines of what I was thinking when I
wrote the first post, though I admit I wasn't very clear about that :-/
I don't want to start the C/C++ Vs. Java argument all over. People are
ultimately the ones who introduce security problems, and people are
ultimately the ones who find them. Tools and verifiers get you part of
the way, but at some point along the way code needs to be read by a
human expressly with the purpose of finding vulnerabilities. Unlike
functionality defects, which are generally ferreted out by having lots
of eyeballs, security defects are usually a little more subtle.
How does this get dealt with in an open source project where security is
of high importance?
OpenBSD has a required audit for all submissions, if I understand
correctly. Is something like that required? The problem with such
processes and requirements is that it starts to feel like my job :-)
Since people are itchin' to get going on code there will probably be a
phase of seed code which is torn apart, and lots of stub functions and
so forth. All this thrashing usually results in a pieces of code which
were never fully dealt with correctly. It's inevitable, IMHO. So how do
we combat this from the perspective of preventing vulnerabilities to
"ship" with milestone releases? Should we require a peer review on every
package, or component, or file? If PGP signatures are required, then a
script can be written to tell us what has not been read. But this gets
back to a process, and that may be two heavy weight for this particular
group. What solutions have people seen in other communities which has
worked? I'm particularly interested in Apache's approach (I assume there
is one).
My main concern is that Harmony will get to a milestone, say 1.0, and a
massive effort will be required to search for security holes. That is
the worst case scenario in my opinion. If this J2SE implementation is
going to be taken seriously, then people need to trust it, and that is
not the way to build trust.
>
> For checking we'll probably be adding tests to Mauve for various
> security things as we start working on the security infrastructure in
> libgcj. These kinds of tests still miss a lot though.
>
> One idea we've discussed a little is writing new FindBugs checks to
> look for the required security calls. But this doesn't protect us
> from bugs in the native code or bugs allowing access to non-standard
> weird things that shouldn't be generally accessible (we have some
> interesting code in gnu.gcj.*).
>
> Tom
I'm all for the use of tools to scan for common errors. I'd like to hear
more about people's experience with different verifiers.
Neil
Re: Security
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Ben" == Ben Laurie <be...@algroup.co.uk> writes:
Ben> I can't think of _any_ other interesting security properties that Java
Ben> has and C lacks. Am I missing something?
Probably not. At some point any VM has to do untrusted things. There
may be reasons that this "window" is bigger or smaller, and smaller is
probably preferable, but it doesn't seem to me to be a necessary
consequence of the implementation language.
That said, it does make sense to think not only about how to implement
security, but also how to verify it, and likewise how to ensure the VM
remains secure in the face of a lot of mutation.
For checking we'll probably be adding tests to Mauve for various
security things as we start working on the security infrastructure in
libgcj. These kinds of tests still miss a lot though.
One idea we've discussed a little is writing new FindBugs checks to
look for the required security calls. But this doesn't protect us
from bugs in the native code or bugs allowing access to non-standard
weird things that shouldn't be generally accessible (we have some
interesting code in gnu.gcj.*).
Tom
Re: Security
Posted by Ben Laurie <be...@algroup.co.uk>.
Neil Macneale wrote:
>
> Hello All-
>
> I've been lurking for awhile and I think the significant discussion
> about security in the Harmony JVM has been missing. Considering such
> ideas as hot compiling code and making it executable sets off big alarm
> bells in my head.
>
> One huge pitfall in many software projects is putting off security until
> later. Auditing of code becomes much more difficult as the code base
> become large. Furthermore, as code grows old, people forget how it works.
>
> Somehow the java gods have convinced the world that java is secure. But
> that all relies on a the JVM executing as documented and with no
> security holes of it's own. The number of ways in which a JVM could open
> security vulnerabilities in a system is enormous, and this is amplified
> by the fact that the language it self has a security model which is
> fairly complex.
>
> One of the reasons I am in favor of implementing as much of the JVM in
> Java is that I think it is easier to write secure code in Java than in
> C/C++. A small core in C/C++ would be reasonable, but from a reviewers
> standpoint it is more difficult to guarantee that a piece of C code is
> secure. Generally speaking, of course.
>
> I'd be happy to read people's code and look for bugs, and I may end up
> doing this just for yucks. Are other people concerned about this?
> Thoughts, comments?
I was initially tempted to say "those who do not read the archives are
doomed to repeat them" but I guess this is (yet another) slightly
different slant on the debate.
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?
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Security
Posted by Daniel Feinberg <cs...@gmail.com>.
I have done some work with Java VMs in java, esp. JikesRVM with IBM.
Not only is the code gueranteed to be more secure it makes writting
the virtual machine and gc code easier. As all things written in
object oriented code, the virutal machine is no different. I think
writting the code in Java is a great idea.
Just an on looker for now.
--
Daniel Feinberg
http://www.cs.unm.edu/~danielf
Re: Security
Posted by Weldon Washburn <we...@gmail.com>.
On 6/30/05, Neil Macneale <ma...@theory.org> wrote:
>
>
> One of the reasons I am in favor of implementing as much of the JVM in
> Java is that I think it is easier to write secure code in Java than in
> C/C++.
I agree with this observation.
I was at Java One this week. Two days ago during a Q and A session
with Sun's Mustang engineering team, the question was asked if they
implemented Mustang in Java. The answer was something like, "Sunlabs
is doing research in building a JVM in java. When they get it
correct, Mustang will incorporate it. Mustang currently has a lot of
C/C++ code."
I also see merit in this observation.
Weldon