JavaTM security architecture (JDK1.2)
1 Introduction
Since Java technology has started applying, people are more and more interested in the security of Java platforms and security issues that deploy Java technology.
According to Java designers, Java security includes two aspects:
As a safe, installed platform, which is secured to the user (mainly passed JDK), on which the Java application can be run safely. Provides security tools and services implemented with Java programming languages, which makes it possible to apply Java technology in some areas such as the business world.
This article will discuss the content of the first aspect, and users who apply this technology include bundling Java technology or embedded in their own products (such as browser and operating system vendors).
1.1 initial sandbox model
It is well known that the original security model provided by the Java platform is a sandbox model, which is set to establish a very limited environment, in which the untrusted code acquired from the open network can be run. The essence of the sandbox model is that the local code is credible, so you can access key system resources (such as file system); download remote code (an applet) is untrustworthy, so it can only be accessed by the interior of the sandbox Provided limited resources. This sandbox model is shown below:
The sandbox model is deployed through the Java Development Kit (JDK). In general, it can be adopted by the application established by JDK1.0 (including web browsers that can run Java).
The improvement of total security is achieved by using a series of mechanisms. First, the Java language is designed to be type security and easy to use, and its purpose is to reduce programmers' burden, reducing programming errors that occur when using other programming languages (such as C or C ). The language features, such as automatic memory management, memory garbage collection, and string and array crosstalk, which can become the language of the language help programmer to write security code.
Second, the compiler and bytecode checkor guarantees that only legal Java bytecodes can be executed. The bytecode checkor with Java virtual machines guarantees the language security during runtime.
Again, the class loader can define a local namespace, which ensures that an untrusted Applet does not interfere with the operation of other programs.
Finally, access to important system resources is passed through the Java virtual machine and is pre-inspected by the SecurityManager class, which limits the activity of untrusted code to the smallest level.
JDK1.1 introduces the concept of "signed applet" as shown below. In this release, an applet with the correct number sign, if its signature is received, the final system of the applet is confirmed, then this applet is considered a trusted code. The signed applet is issued in JAR (Java Archive) with their signs. In JDK1.1, the unqualified Applet is always running in the sandbox.
1.2 Evolution of Sandbox Model
The new security architecture (shown below) in JDK1.2 is mainly introduced for the following purposes:
Exquisite access control This ability exists from the beginning, but to use it, the application's writer has to do a large number of programming work (for example, create subclasses for SecurityManager and ClassLoader classes and make it userize) . HotJava1.0 is a such application that allows the browser user to choose from several different security levels. However, this programming involves very sensitive security issues, which requires programmers to have a deep understanding and sake of software security. The new security architecture will make these simple and safe. Easy to set security policies are similar to those described above, which exists in the original JDK, but not for use, and writing security codes is not simple. Thus, it is expected that the application's writers and users can set the security policy without programming. Easy to expand the access control structure until JDK1.1, in order to create a new access license, you must add a new Check method in the SecurityManager class. The new security architecture allows you to set various types of access licenses (each representation of access to a system resource) and automatically processes all correct access licenses (including undefined licenses). Under most cases, you don't have to create a new method in the SecurityManager class (in fact, we have never encountered the case of the new way to create new methods). Extending security checks to all Java applications, including applications and applets, all local code is a trusted built-in concept, will not exist, replaced, local code (such as non-system code, mounted locally) Application packages, etc.) Obtain the same security control as Applet, although (if needed), you can declare that the policy of local code (even remote code) is tolerate, so that these code can be considered completely credible Effectively run. The above principles can also be applied with the signed Applets and any Java application. All in all, the purpose of the above approach is undoubtedly to do internal adjustment (including SecurityManager and ClassLoader classes) for security classes to reduce the risk of safe cave in future programming. ........ | Next | ..........
Welcome to contact us: Webmaster@prc.sun.com Copyright 1997-1998 Sun (China) Company, 16th Floor, Jianwei Building, No. 66 Beijing Nanke Road
