Java Reference
In-Depth Information
realized that the difference between an attack and a bug was often the intention of the pro-
grammer, so these features were also seen as security enhancements.
The JVM also has a set of security models that can enforce different access rights on different
parts of code. I'm not going to talk about this security model (or, perhaps more accurately, the
set of security models that have been layered on top of each other) since it is complex, difficult
to understand, and generally ignored or overwritten by users (who almost all have security
policy files that allow all code to have all permissions). This is a book about the good parts of
Java, and I'm not convinced that the security mechanisms should be included. This is not to
say that those who invented the series of Java security models and mechanisms weren't very
smart people with the best of intentions. But like many other security systems, both inside and
outside of the Java environment, getting good security often requires trading off usability.
But the flaws in verification and complexity of the security model should not obscure an im-
portant fact about the JVM with respect to security. Java in general, and the JVM in particular,
try to give the programmer a secure environment. It may not be fully immune from the most
sophisticated attacks, but it is better than most other alternatives. It is somewhat ironic that
the JVM has been so often faulted for security failures when it is one of the few environments
that has attempted to give some measure of security. Go figure. Even with its flawed security,
Java as an environment is more secure than the alternatives.
Because the JVM enforces a security model that was originally tied to the Java language, it
is not always possible to have a language hosted on the JVM that is exactly like the language
when it is compiled to native object code. The bytecodes generated for every language will be
the Java bytecodes, and the restrictions enforced by the verifier on sequences of bytecodes are
tied to the Java language. So if you are using a language that generates bytecodes so that you
can use the JVM as your virtual machine, make sure to check the small print of the document-
ation. There may be some language idioms that are outlawed in the hybrid environment, but
many of those that are outlawed are restricted for your own good. Not having them makes for
a more secure program.
Portability
The security offered by the JVM is a good thing, and it certainly gets a lot of press and a lot
of discussion. But the real reason that the JVM is a good thing is that it makes the code you
write portable. That is, the JVM isolates you from the chip and the operating system on which
your program is going to run in such a way that any program that you write ought to run on
any computer and operating system that has a JVM. And I'm not talking about your source
