JavaTM security architecture (JDK1.2) 4. Access control mechanism and algorithm 4.1 java.security.protectionDomain
This class represents a protective unit in the Java application environment, which is typically associated with the concept of "Principal)", where the subject is a entity granted in the computer system.
From a conceptual, a domain is a collection of classes that are granted the same license set. Currently, a domain is individually identified by a code source (CODESource), which encapsulates two features of the code running in this domain: code base (java.Net.URL) and public key certificate set (belonging to Java) .security.cert.certificate type), the public key corresponds to a private key that is signed all of the code in this domain. Thus, classes from the same key and from the same URL are placed in the same domain.
One domain is also included in the field to grant code, which is determined by the current security policy.
Has the same license, but classes from different code sources belong to different domains.
A class belongs to one and belongs to a protectionDomain.
Note: Currently in JDK1.2, the protection domain is created as a result of a class load. The GetProtectionDomain method in java.lang.class can be used to query the protected domain associated with the given class. But you must have an appropriate license (GetProtectionDomain) to successfully call the method.
Today, all code submitted as a JDK component is considered system code that is running in a separate system domain. Each applet and application run in its appropriate domain, which is determined by its code source.
It is possible to ensure that objects in any non-system domain cannot automatically discover objects in another non-system domain. This segmentation can be obtained by carefully analyzing and loading. For example, different types of loads are used for different domains. However, SecureClassLoader (or its subclass) can be loaded from different domains (optionally), which allows these classes to coexist (divided by the class loader) in the same namespace.
4.2 java.security.accessController
There are three purposes using the AccessController class, and each purpose will be detailed below:
Determine if access to key system resources is determined in accordance with current security policies. Identify some code to "privilege" code, which affects subsequent access decision. A "snapshot" currently called the context relationship is obtained, which can make an access control decision according to different contextual relationships.
Control any code to system resource access If you want to use a special security model or access the access control algorithm called by the AccessController method, it should call the AccessController method. On the other hand, if the application wishes to delay the security model to SecurityManager is installed at runtime, it should call the appropriate method in SecurityManager.
For example, a typical way to call access control has been as follows (from earlier versions of JDK):
ClassLoader Loader = this.getClass (). GetClassLoader ();
IF (loader! = null) {
SecurityManager security = system.getsecuritymanager ();
IF (security! = null) {security.checkread ("path / file");
}
}
Under the new architecture, the check should be called whether or not there is a class-loaded load associated with a call class. This may be simple, for example:
FILEPERMISSION Perm = New FilePermission ("Path / File", "Read");
AccessController.checkpermission (Perm);
Method for Class AccessController Checkpermission checks the context of the current executing program, and makes correct decisions on whether the requested access is allowed. If the request is allowed, this check will return quietly; otherwise, an exception will be thrown out of an AccessControlleRexception (a subclass of java.lang.securityException).
Note: There are some (original) typical examples. For example, in some browsers, whether securityManager is installed means such or such security states, it may result in different actions. For backward compatible considerations, you can call the Checkpermission method in SecurityManager:
SecurityManager security = system.getsecuritymanager ();
IF (Security! = null) {
FILEPERMISSION Perm = New FilePermission ("Path / File", "Read");
Security.checkpermission (Perm);
}
Currently, we do not change the use of SecurityManager in this area, but encourage application developers to use new JDK technology in programming when the built-in access control algorithm is appropriate.
SecurityManager's method CheckperMission The default behavior is actually calling AccessController's method Checkpermission. A different SecurityManager implementation may implement its own practice, it is possible to include: Whether it is determined whether it is allowed to increase further restrictions.
4. 2. Algorithm for checking the license
Suppose the access control check occurs within a computing thread with a multi-adjuster chain (considering it as a multiple method call to a cross-protected domain limit). As shown below:
When the Checkpermission method of AccessController is called by a nearest caller (for example: a method in the File class), decide whether to allow an access request to the basic algorithm as follows:
If any of the calls in the calling chain do not have the requested license, the exception AccessControlexception is thrown out. Here there is an exception: a caller (its domain is granted the above license) is identified as "privilege" (see section), and all the partitions called by the caller have (direct or indirectly) the above license .
Obviously, there are two implementation strategies:
In a "EAGER Evaluation" implementation, the valid licenses are dynamically updated regardless of when a thread enters a new protected domain or exits from it. The above strategy is that it simplifies and accelerates whether a license is allowed to be permitted; and its disadvantage is that because the time to check the occurrence frequency than the occurrence frequency of the interval, a large number of licensed updates seem to be useless. work. In a "Lazy Evaluation" implementation, both the thread state (such as the current state reflected, including the call stack of the current thread, or its equivalent) of the current thread, or its equivalent substitutes, regardless of the license check, and make a negative or grant specific Visit decision. A potential disadvantage of this method is that performance is declining during license check, although this decline may also occur in "Eager Evaluation" practice (although it takes earlier and is in each crossover) diffusion). So far, our implementation has produced acceptable performance, so we feel "Lazy Evaluation" is a most affordable approach.
Therefore, the algorithm currently inspecting the license is implemented as "lazy evAaluation". Assuming the current thread is traversed by the M-called in the caller 1, the caller 2 until the caller M, and the caller m calls the Checkpermission method. Checkpermission is used to determine if the access to whether the basic algorithm is granted as follows:
i = m;
While (i> 0) {
Caller I's Domain Does Not Have The Permission
Throw AccessControlException
ELSE IF (Caller i is marked as privileged)
Return;
i = i - 1;
}
4.2.2 Privilege Processing
A new method in the AccessController class, allows this AccessController to notify this code in a class instance: its code main body is "privileged", which is responsible for access requests for its availability resources No matter what code is caused by this request.
That is to say, a caller can be identified as "privilege" when calling the DOPRIVILEGED method. When doing access control decisions, if the Checkpermission method is called "privilege" by a DOPRIVILEGED call, there is no context independent variable (see the chapter of the context of the context), the checkpermission method will terminate the check . If the caller's domain has a specific license, you do not check, checkpermission returns quietly, indicating that access request is allowed; if that domain does not have a specific license, it is usually the same, an exception is thrown out.
The "privilege" features are normal use as follows:
If you don't need to return a value from the "privilege" block, press the following code to do:
SomeMethod () {
... Normal Code Here ...
AccessController.doprivileged (new privilegedaction () {
Public Object Run () {
// Privileged Code Goes Here, for example:
System.LoadLibrary ("AWT");
Return null; // Nothing to returnon}
});
... Normal Code Here ...
}
PrivilegedAction is an interface that has a method called RUN that returns an Object. The above example shows an creation of anonymous within that interface to implement that anonymous, and provides a specific implementation of a RUN method. When as a DOPRIVILEGED call, an instance of a privilegedAction implementation is passed to it. The DOPRIVILEGED method is called the RUN method from the PrivileDAction implementation, and returns the return value of the RUN method to the return value of the RUN method, which is ignored in this example.
(For further information on internal category, see Inner Classes Specification, it is located
Http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclass
Or some chapters of More Features of the Java Language, including:
http://java.sun.com/docs/books/tutorial/java/more/nested.html and
http://java.sun.com/docs/books/tutorial/java/more/innerclasses.html)
If you need to return a value, you can do it as follows:
SomeMethod () {
... Normal Code Here ...
String user = (string) AccessController.doprivileged
NEW privilegedaction () {
Public Object Run () {
Return System.getProperty ("User.Name");
}
}
);
... Normal Code Here ...
}
If the action performed by your RUN method may throw an "check" exception (including in a list of throws clauses), you need to use the PrivileGedExcectionAction interface instead of using the PrivilegedAction interface:
SomeMethod () throws filenotfoundexception {
... Normal Code Here ...
Try {
FileInputStream Fis = (fileInputstream)
AccessController.doprivileged
New privilegedExcectionAction () {
Public Object Run () throws filenotfoundexception {
Return New FileInputStream ("Somefile");
}
}
);
} catch (privilegedactionexception e) {
// E.GETEXCEPTION () SHOULD BE An Instance of
// filenotfoundexception,
// as Only "Checked" Exceptions Will Be "Wrapped" in A
// privilegedactionException.
THROW (FilenotFoundException) E.GETEXCEPTION ();
}
... Normal Code Here ...
}
Some important things about being granted privilege: First, this concept exists only within a separate thread. Once the privileged code completes the task, the privilege will be guaranteed to clear or invalid. Second, in this example, the code body in the RUN method is granted privilege. However, if it calls no privy untrusted code, then that code will not get any privilege; only the subsequent caller of the privilege code is licensed and all subsequent caller in the CHECKPERMISSION calls is also licensed, one license Can be granted.
For more information on obtaining privileges, see:
Http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html
4.3 Access Control Context Inheritance
When a thread creates a new thread, a new stack is created. If this new thread is created, the current security context is not retained, and when AccessController.checkpermission is called in the new thread, the security decision can only be made according to the context of the new thread, regardless of the parent thread.
The problem of this clear stack is in essentially, it is not a stack itself, but it makes the security code, especially the writing of the system code, is prone to errors. For example, a non-professional developer is very likely to envisage: a sub-thread (for example, a sub-thread that does not introduce invisible code) will inherit the same security context from the parent thread (e.g., a parent thread that introduces untrusted code). This will access control resources from the new thread (and then pass the resource to less credible code), causing unpredictable security holes (if the positive context is not stored in facts).
This way, when a new thread is created, we actually guarantee (creating and other code through thread) that it can automatically inherit the security context of the parent thread when the sub-thread is created. In this way, the subsequent CheckperMission call in the subclink will take into account the inherited parent context.
In other words, the logic thread context is extended, which includes both parent context (in the form of an AccessControlContext, the following will also be discussed), including the current context; the algorithm for checking the license is expanded as the following form (recall, until calling checkpermission, a total There are M-modes. For information on the AccessControlContext checkpermission method, please see the next section):
i = m;
While (i> 0) {
Caller I's Domain Does Not Have The Permission
Throw AccessControlException
ELSE IF (Caller i is marked as privileged)
Return;
i = i - 1;
}
// next, check the context inherited
// The Thread Was Created. WHENEVER A New Thread Is Created, THE
// AccessControlContext At That Time IS
// stored and associated with the new three, as the "inherited"
// context.
InheritedContext.Checkpermission (Permission);
Note: This inheritance can be pushed. For example, a grandchildren inherited its father and inherited its grandfather.
Also note that inheritance context snapshots are done when new children are created, rather than being completed at the first runtime. Inheritance characteristics cannot be changed in the public API.
4.4 java.security.accessControlContext
Recall that AccessController's Checkpermission method performs security checks in the context of the current thread (including inheritance context). It will only be difficult when such a security check can only be performed in different contexts. This is, sometimes the security checks should be performed in a given context, actually need to be performed in different contexts. For example, when a thread registers an event in another thread, the second thread serving the request event will not have a real context to complete access control (if the service requests to the control resource). To illustrate this problem, we provide AccessController's getContext method and AccessControlContext class. The getContext method is a "snapshot" for the current call, and put it in one of the ACCESSCONTROLCONTEXT objects. For example, as follows:
AccessControlContext ACC = AccessController.getContext ();
This context captures information, so that an access control decision can make a comparison check with this context in different contexts. For example, a thread can register a request event in the second thread while providing this context information. AccessControlContext has a checkpermission method that can make access decisions based on the context it packaged (not the context of the thread). Thus, if necessary, the second thread can perform an appropriate security check by calling the following code:
Acc.checkpermission (permission);
The above method calls to perform the same security check in the context of the first thread, although it is done in the second thread.
One or more licenses must be checked against the access control context, and there is also an occurrence, but which license is prioritized, it is unclear. In this case, you can use the DOPRIVILEGED method:
SomeMethod () {
AccessController.doprivileged (new privilegedaction () {
Public Object Run () {
// Code Goes Here. Any Permission Checks from
// this Point Forward Require Both The Current
// context and the snapshot's context to have
// The desired permission.
}
}, ACC);
... Normal Code Here ...
Now, all algorithms used by the checkpermission method of AccessController can be given. Assuming the current thread is traversed by the M-called in the caller 1, the caller 2 until the caller M, and the caller m calls the Checkpermission method. The CHECKPERMISSION is used to determine if the algorithm is granted as follows:
i = m;
While (i> 0) {
Caller I's Domain Does Not Have The Permission
Throw AccessControlException
Else IF (Caller i is marked as privileged) {
IF (a Context Was Specified In the Call to Doprivileged)
Context.checkpermission (Permission);
Return;
}
i = i - 1;
}
// next, check the context inherited
// The Thread Was Created. WHENEVER A New Thread Is Created, THE
// AccessControlContext At That Time IS
// stored and associated with the new thread, as the "inherited" // context.
InheritedContext.Checkpermission;
........ | Next | ..........
Welcome to contact us: Webmaster@prc.sun.com Copyright 1997-1998 Sun (China) Company, 16th Floor, Jianwei Building, No. 66 Beijing Nanke Road
