JavaTM security architecture (JDK1.2) 8. Future development direction 8.1 users, certification and trust
Today, the main body (for example: user) is not very clear because each JVM is owned by a user. In the future, it is necessary to extend the existing concept of ProtectionDomain to include the concept of "standing on behalf of a subject."
Therefore, we are enthusiastic to provide you with the following features in the near future:
The concept of clear subjects and user certification primitives (both password-based, other) cross-protected domain principal certification protocol certification and authorization general mechanisms
8.2 Resource Consumption Management
In some cases, resource consumption management is relatively easy to implement (for example, restricting the number of windows that may suddenly appear); in some other case, it is quite difficult to effectively implement (for example, limit memory or files) The use of the system). In the future, we must constantly study this problem.
8.3 Random license group
Sometimes some licenses are combined together and use shortfet names to reference them to simplify our work. For example, we want a license called "superpermission" including (and hidden) FilePermission ("-", "Read, White") and socketpermission ("*", "connect, accept"), from technology Speaking, we can use the class Permission or a similar ADD method to increase the desired class to implement this super license. Such grouping can be any complicated.
More difficult things are: First, it is necessary to understand what kind of license is awarded in a super license, so it must create a fixed, and is a named license class to represent a static designation. The license group; or you need to detail the license for these members in the policy file; second, due to the license of the group may need to be expanded, the processing policy (file) may be more complex; third, the nesting of group licenses is further Added complexity.
8.4 Object Level Protection
Assuming that object-oriented features of the Java programming language can be imagined that developers will benefit from a set of appropriate object-level protection mechanisms. This object-level protection one is natural protection provided by the Java programming language; second, it can supplement the thread-based access control mechanism.
One such mechanism is SignedObject. We will provide object SeaDObject, which use encryption techniques to hide the contents of the object, which is compared with the SignedObject (Since the US current export control regulations on encryption, SealedObject may be provided separately from JDK).
GuardedObject is a general way to enhance access control at each method level of each class / object. However, this method should only be used in selectively, in part because this type of control is difficult to manage on the high layer.
8.5 Creating a domain from the protected domain
A potential and useful concept that is currently not implemented is the concept of "subdomain". A subdomain is included in another subdomain. Licensing and privileges in a sub-domain will not be more licensing and privileges than its parent domain. For example, you can create a domain to selectively limit what a program should do.
The domain is often considered to support inheritance: a subdomain will automatically inherit the security attributes of its parent domain unless in some cases, the parent domain should significantly limit the subdomain. With the concept of credit, it is possible to relax the restrictions on the subdomain by amplification.
For convenience, we can use the system domain as a large collection of individual, all system code. However, in order to better protect, the system code should run in multiple system domains, and each domain protects a special resource type and gives some special power. For example, if the file system code and network system code run in their respective domains, the former has no right to access the resources of the network system, and the latter has no right to access the resources of the file system. The risks and consequences caused by such an error or security defect will be restricted in its own domain.
8.6 APPLETS running with signature content
The JAR and Manifest specification for code signed are allowed to be very flexible. The class in the same document can be signed with a different key, and a class can be signed by a key to sign, or sign by multiple keys. Other resources (such as audio clips and graphics images, etc.) in the document can also be signed or released. How to explain with this flexibility. The following questions need to be answered, especially when the key is taken by different:
1. If any class in the document is signed, the image and audio data should be signed with the same key?
2. If the image and audio are signed with different key, whether they can be placed in the same appletViewer (or browser page), or whether it should be sent to different viewers for processing?
These problems are not easy to answer, they need compatibility cross platforms and the most effective products. Our compromises are to provide a simple answer - all images and audio are sent to the same Applet class loader (whether they are signed or not signed). Once the above issues are reached, this temporary solution will be improved.
Further, if a digital signature is not verified by the bytecode content of a class file and cannot be verified, a security exception is thrown out, because the initial intention of JAR author has changed significantly. . Previously, some people suggested that these codes were run as untrusted code. This idea is unpopular. Because the Applet class loader allows the code to be loaded by multiple parties. This means that the JAR file that accepted some changes will allow a untrusted code to run with the same type of load and access other code through the same type loader.
9 Conclusion
This article outlines the generating motivation of the main security features implemented by JDK1.2 and introduces this new security architecture.
Please feed your evaluation to java-security@java.sun.com (it is archived Web address is: http://java.sun.com/security/hypermail/java-security-archive/index.html). Please send it directly to the author (li.gong@sun.com) if you need to keep confidential. ........ | back | ..........
Welcome to contact us: Webmaster@prc.sun.com Copyright 1997-1998 Sun (China) Company, 16th Floor, Jianwei Building, No. 66 Beijing Nanke Road
