At 04:49 PM 7/18/98 -0500, Greg Alexander wrote: >Is it appropriate to call a java implementation-related security hole a java >hole? That'd be like calling a bug in pine a bug in internet e-mail. As best I recall, all -- and certainly almost all -- of the "Java" bugs have been implementation bugs. And yes, it's perfectly fair to call them "Java bugs", because in my opinion bugs of this nature are *invevitable* in *any* Java implementation. The fundamental problem lies in the very nature of the Java security model. The safety of the sandbox depends on a very complex set of semantics, plus a very complex set of checks that have to be done at runtime, all coupled with the lack of "system calls" in the Java Virtual Machine. Complexity is the enemy of security; here, security rests entirely on a very complex structure. I don't believe that it is possible for implementors to get this right -- ever. We thus have a situation where the nature of the environment is conducive to bugs. This is, of course, the same issue being discussed in another thread -- C's suitability as a systems language. It is certainly true that one can write secure programs in C. It's equally true that it's harder. A simple set of library routines, analogous to the String class in C++, would have made life much better -- *if* it had been implemented circa 20 years ago, when stdio was introduced, because it would now be a standard part of the language. My own research interests concern the question of how to make it possible to write more secure program. See http://www.research.att.com/~smb/talks/odds.ps (or the corresponding .pdf file) for some early thoughts.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:49 PDT