Sponsored Link •
The problem of native methods
Basically, when you call a native method, Java's security sandbox becomes dust in the wind. First of all, the guarantees of robustness don't hold for native methods. Although you can't corrupt memory from a Java method, you can from a native method. But most important, native methods don't go through the Java API (native methods provide a means of going around the Java API), so the security manager isn't checked before a native method attempts to do something that could be potentially damaging. Of course, this is often how the Java API itself gets anything done. Many Java API methods may be implemented as native methods, but the native methods used by the Java API are "trusted."
Thus, once a thread gets into a native method, the security policy established inside the Java virtual machine -- no matter what is is -- doesn't apply anymore to that thread, so long as that thread continues to execute the native method. This is why the security manager includes a method that establishes whether or not a program can load dynamic libraries, which are necessary for invoking native methods. If untrusted code is allowed to load a dynamic library, that code could maliciously invoke native methods that wreak havoc with the local system. If a piece of untrusted code is prevented by the security manager from loading a dynamic library, it won't be able to invoke an untrusted native method. Its malicious intent will be thwarted. Applets, for example, aren't allowed to load a new dynamic library and therefore can't install their own new native methods. They can, however, call methods in the Java API, methods that may be native but that are always trusted.
When a thread invokes a native method, that thread leaps outside the sandbox. The security model for native methods therefore is the same traditional approach to computer security described earlier: You have to trust a native method before you call it.
Structured error handling
One final mechanism that is built into the Java virtual machine and that contributes to security is structured error handling with exceptions. Because of its support for exceptions, the JVM has something structured to do when a security violation occurs. Instead of crashing, the JVM can throw an exception or an error, which may result in the death of the offending thread but shouldn't crash the system.
Throwing an error (as opposed to throwing an exception) almost always results in the death of the thread in which the error was thrown. This is usually a major inconvenience to a running Java program, but won't necessarily result in termination of the entire program. If the program has other threads doing useful things, those threads may be able to carry on without their recently departed colleague. Throwing an exception, on the other hand, may result in the death of the thread, but is often just used as a way to transfer control from the point in the program where the exception condition arose to the point in the program where the exception condition is handled.
Structured error handling contributes to Java's security model by helping to improve the robustness of Java programs. The Java compiler forces programmers to deal with exceptions that methods declare they may throw. This encourages programmers to write code that actually handles exception conditions that may reasonably be expected to arise as their programs run. If a program encounters a catastrophic error condition, the structure error handling mechanism enables the program to avoid an uncontrolled crash and make a more graceful exit.
The sandbox security model is an intrinsic part of Java's architecture. The sandbox, a shell that surrounds a running Java program, protects the host system from malicious code. This security model helps give users confidence in downloading untrusted code across network.
The sandbox is designed into the Java virtual machine and Java API. It touches all corners of the architecture, but can be divided into four main components:
About the author
Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill. Reach Bill at firstname.lastname@example.org.
This article was first published under the name Java's Security Architecture in JavaWorld, a division of Web Publishing, Inc., July 1997.