|
|
|
Java Security Model Three Fundamental Layers There are three fundamental layers that compose the Java Security Model:
The Java language The important features of the language from a security standpoint are:
This means that the compile time type and the runtime type of variables are guaranteed to be compatible. This prevents the forging of access to objects to get around access control.
Pointers cannot be directly manipulated by user code. This then prevents both malicious and accidental misuse of pointers.
The Java language uses this to recover unused memory instead of relying on explicit user deallocation. This eliminates not only an extremely common class of bugs, but also potential security holes.
Java has means for controlling the access to the variables and methods of objects. These access controls allow objects to be used by non-trusted code. An example of this is that the Java library contains a definition for a File object. The File object has a 'public' method, which is callable by anyone for reading, and a low-level 'private' method, which is only callable by the objects method for reading. The public read call first performs security checks and then calls the private read. The Java language ensures that nontrusted code can safely manipulate a File object, providing only access to the public methods. The access control facilities allows programmers to write libraries which are guaranteed by the language to be safe by correctly specifying the library's access controls.
These provide namespace encapsulation. These packages are useful because they allow downloaded code to be easily distinguished from local code. The Libraries The Java runtime environment comes with a vast selection of useful libraries that provide file system access, network access, a window toolkit, and a variety of other tools. The correct specification of the libraries is critical. The language itself can provide the ability to create secure libraries, but if the library code is not specified and written correctly the system is not secure. There are three mechanisms that the access restrictions of the libraries are based on. The first is the Java language mechanism of providing access restrictions to object methods and variables. The second is the use of specialized 'ClassLoaders' to load imported code. The last is the use of explicit calls to a global 'SecurityManager' that checks the validity of certain specific operations. The Web Browser The Web Browser defines a set of rules for running downloaded Java code. A Java enabled Web browser will include a Java interpreter and a runtime library along with classes added to implement a SecurityManager and various ClassLoaders. From a security standpoint, the Web browser's implementation of the SecurityManager is much more critical than the implementation of the Classloaders. The SecurityManager controls the access to critical system resources. If a Java enabled Web browser did not install a system SecurityManager, an applet would have the same access as a local Java application. The Design of the Java Security Model The Java security model is based almost entirely on the ability to verify the downloaded bytecode, the ability to specify and write libraries that prevents undesired access to resources, and the ability of Web browser developers to specify and write code that implements good security policies. There are a number of reasons for using bytecode vs. Java source code. It prevents reverse engineering of Java programs. The bytecode representation is somewhat smaller. The process of verification is faster than the process of compilation. And, a final viewpoint is that the bytecode verifier is a less complex program than a full compiler, so the verification of the correctness is a simpler process. The "Sandbox" Java security relies entirely on software technology. Java accepts all downloaded programs and runs them within a security "sandbox". This can be looked at as a security fence that surrounds the program and keeps it away from your private data. As long as that fence has no holes, data is safe. Java security relies on the software implementing the sandbox to work correctly. A Java program must play only inside its sandbox. It can do anything within the boundaries of its sandbox, but it can't take any action outside of those boundaries. For example, the sandbox for untrusted Java applets prohibits many activities including:
The Java virtual machine (JVM) restricts applets from accessing the local file system entirely, and this includes stopping applets from reading and writing files within the local system. This Java "sandbox" defines the strict security boundaries by which Java programmers are constrained. The problem is, as time goes by, Java programmers will want more flexibility and more client access for their programs. To support their needs, the Java sandbox must be converted into a "playground" in which there are still constraints, but a little bit more flexibility. How can Java be dangerous or disadvantageous? Java's main danger is from the complexity of the software that implements the sandbox. Since Java is complicated, complicated technology is more likely to break down than simple technology. When Java security does break down, a hostile program can come to your machine and access your data. The Java language has neither a formal semantics nor a formal description of its type system. The module system is weak, the scoping rules are too liberal, and methods may be called on partially initialized objects. Java lacks a formal description of its type system but the security of Java relies on the soundness of its type system. DS420 Project |
| Home Digital Certificates Firewalls Cryptography SSL JAVA |
