JavaTM security architecture (JDK1.2)
2. New Protection Mechanism - Basic Concept Overview
Now, we discuss a new protection architecture and make a brief description of its functionality. We will start from the basic concept of the new architecture, then introduce the main new classes according to the natural order, that is, start from the license instructions, then the strategy and related features and access control and its use, and finally the safe class loading and solution .
An important building block for a basic concept and system security is a protection domain. One domain can be divided by an object set, which can be directly accessed by one subject. The body is an entity that is granted permission (the result of the license) in the computer system. The sandbox for JDK1.0 is a protected domain example with a fixed boundary.
The concept of protecting domains is a convenient mechanism that plays a packet and isolation between the protection unit. For example, we can (not available as a built-in feature) separately separate the protected domain to avoid direct interactions between them, so any allowed interaction must pass through trusted system code or related domain Explicitly allow. Note that under the new security architecture, the existing object access rules are still valid.
The protection domain is usually divided into two categories: system domain and application domain. Importantly, all protected external resources (such as file systems, network facilities, and keyboards, etc.) can only be accessed through the system domain. The figure below shows the composition of a Java application environment.
Conceptually, a domain includes a set of classes that are granted the same set of licenses. The protection domain is determined by the current policy. The Java application environment maintains mappings from code (classes and instances) to their protection domains and then to their licensed. As shown below:
A thread that is performed (it is often a single Java thread, but it is not necessarily dependent on this single Java thread, nor does it depend on the thread concept of the underlying operating system) may completely occur in a single protection domain, or It involves an application domain or a system domain. For example, an application for a print message will have to interact with the system domain because the system domain is the only access point for the output stream. In the case of the application, the application domain cannot obtain any additional licenses outside the print message by calling the system domain. This is critical. Otherwise, there may be serious security hazards.
In the opposite situation, a system domain calls a method from an application domain, such as when an AWT system domain calls an applet's painting method to display this applet, the valid access to the current permission allowed by the application domain in any This is the same, this is also the same.
In other words, a domain that is not "power" cannot obtain additional licenses by calling a stronger domain or by a more powerful domain.
The above-mentioned thread involves discussions in two guards naturally summarizes a thread that traverses multiple protected domains, and a simple and cautious experience of calculating licensing is:
A permission set that performs threads can be considered a integration of all protected domains traversed by the thread. When a code calls the DOPRIVILED method (see below), the permission to execute the thread is considered to include a license, if the license allows for the protection domain of the code to be allowed and called or later, indirectly enters the protected domain allowed .
Just like you can see, pass the DOPRIVILEGED method to make a trusted code can temporarily access more resources. This is necessary in some cases. For example, an application may not be allowed to directly access files containing fonts, however, the system utility displaying text must obtain those fonts on behalf of users. We provide a DOPRIVILEGED method for system domains to handle this situation, in fact, this method can be called in all domains.
During execution, when requesting access to a critical system resource (such as file I / O and Network I / O), resource processing code directly or indirectly calls a method of special AccessController classes, which evaluates the request and decides whether it is granted request. This assessment is tightly followed by the "Experience" mentioned above and summarizes the "experience practices". The practical approach to evaluate can vary depending on the implementation method. Its basic principle is to check the license for calling history and related protected domains. If the request is granted, then returns quietly, but throw a safe exception.
Finally, each domain (system or application) can also be attached to the internal resources within its domain boundaries. For example, a bank system application may need to support and protect some of its internal concepts, such as checking, deposits, and withdrawals. Since the semantics of this protection is generally unpredictable, JDK is not implemented, so it is best to leave the system or application developer in this level of protection. Despite this, we are still willing to provide a certain method for simplifying programmers at the time, one is the SignedObject class, and we discuss its details later. ........ | Next | ..........
Welcome to contact us: Webmaster@prc.sun.com Copyright 1997-1998 Sun (China) Company, 16th Floor, Jianwei Building, No. 66 Beijing Nanke Road
