Java Virtual machine-insurance sandbox

Java Virtual machine-security sandbox

"Java Virtual machine"-Security sandbox

Learn the Java security mechanism, the previous learning C + + seems to have never considered too many security issues, some code security issues, such as pointers, memory what has been considered, but the overall security of basic disregard, learning this chapter or there is a lot of harvest.

Sand Box

Four components that make up a sandbox:

• Class Loader
• class File Verifier
• Security features built into Java virtual machines
• Security Manager

class Loader

Classes are isolated through namespaces, so that classes of different namespaces do not access each other (with exceptions that specify the access method), which resolves the scope of the class's access issues, such as:

Class loading (loading) order problems and methods to prevent malicious loading, look first:

The network class loader in is understood as a user-defined loader, the startup class loader is Java's top class loader (top level presentation hierarchy, not performance, taste, luxury, etc.) and the standard Extension class loader understands the class loader as the system comes with.

example, when the need to load Class A, the first from the parent loader to find out if Class A already exists, if not, the iteration looks for the parent loader, until the startup class loader returns the results, if found, is loaded by the parent loader, if not, it is loaded by itself.

The class loader load class has some protection rules, as follows:

1. The way the class is loaded with the parent loader overrides the system class being replaced. example, loading Java.land.Integer from the network will be rejected because the Java API loaded by the boot class loader already exists, so the original integer is not replaced.
2. Only classes that are loaded by the same class loader and within the same package can access each other. Example, a self-written virus class Java.lang.Virus, because the system does not exist in the class, so the above constraint 1 is invalid, loaded by the network class loader successfully, and the Java.lang.* class in the same package, but because the class loader is not the same, So virus also cannot access java.lang.*.
3. Add blacklist. The class loader can specify a list of classes that are forbidden to load, and throws an exception immediately if an attempt to load is found.

class File Verifier

Security begins to enter the inside of the class. The Java Virtual machine has 4 checks on the class file:

1. The structure check of the class file. Occurs when the class is loaded. File format check, check Baotou, version, file length and so on.
2. Semantic checking of type data. During the connection process. The class File Checker examines some of the mandatory rules that the Java language should follow at compile time at run time.
3. BYTE code verification. During the connection process. My understanding is to check the method, the other side of the law (Operation code, operation number) to check to ensure that the correct access. Because of the "downtime problem", the rules for checking are a specific set of rules, not all possible cases.
4. The validation of the symbol reference. This is a check of external calls during a dynamic connection. example, Noclassdeffounderror does not pop up during the preload process, but only pops up until the non-existent class is first used by the program. By the way, when dynamically connecting, look for the referenced class (Load the class if necessary) and convert the symbolic reference to a direct reference (pointer, offset).

Binary compatibility issues, why check for dynamic connections (fourth above), one reason is to prevent the original class from changing, there are special binary compatibility rules to describe which conditions are compatible. For example, the newly added method in the called class is possible, but renaming the old method is not possible. My personal understanding is: The symbolic reference method for dynamic connection, as long as the symbol is not changed, OK, the symbol changed.

security features built into Java virtual machines

Repeat, before also have understanding, write more, right when is recite.

• Type-safe reference conversions (force display type conversions)
• Structured memory access (no pointers)
• Automatic garbage collection
• Array bounds checking
• null reference check

Here's what you didn't know before:

• The run-time data space distribution is not specified. The Java stack (one per thread), the method area, and the garbage collection heap do not pre-specify the memory address and are allocated only by the Java Virtual machine at run time.
• The local method is not limited by the security of the Java Virtual machine. As soon as you start running the local method, you jump out of the Java Virtual Machine sandbox. It is safer not to call local methods directly from the Java API, which can be controlled by the security of the Java API itself.
• Thread death does not affect other threads.

Security Manager

Each Java application has only one policy object, The current policy object can be replaced with the new policy object by Java.security.Policy.setPolicy (), which is used by the class loader to help it decide what permissions to give to a piece of code when it is imported into the virtual machine, and the class loader can add its own or ignore the permissions of the policy.

About Code sources (Codesource), signatures, and protection domains are used only for a little explanation:

The example is the friend class compiled for Friend.class and friend$1.class two files, packaged as Friend.jar, in the method area for friend and Friend$1 (which I don't quite understand yet). You need to limit its permissions on Question.txt and answer.txt two files.

• Codesource by the unique code URL and signature [0 ... N] consists of friend.jar and friend signatures in the file system, which can be signed without.
• A file's permissions are one of the permissions, and a permission (Permission) is represented as a type, property, and action. such as Filepermission, "Question.txt", "read" indicates that the file permission for Question.txt is read.
• Multiple permissions are composed of PermissionCollection, which is represented as permissions.
• A protection domain (PROTECTIONDOMAIN) is the association of Codesource with multiple permissions.

The policy object has a Getpermission method that, by passing in a codesource, can obtain its corresponding permissions.

Access Controller

Java.security.AccessController provides a default security policy enforcement mechanism that uses a stack check to determine whether an operation is allowed. This class cannot be instantiated, it contains only a number of static methods.

The core function is void checkpermission (Permission), which, if allowed, simply returns and, if not allowed, throws accesscontrollerexception or its subclasses.

The old version takes a direct function call, simplifying the old version of the function in the Java1.2 version to: Instantiate the corresponding permission and invoke the Checkpermission function.

Permission, PermissionCollection, and protectiondomain all have a implies (Permission) method, The role of implies in permission is to see if its own permissions contain permission permissions in the parameter. The role of the implies of PermissionCollection and Protectiondomain is to see if the permissions of the collection are in the permission of the parameters.

Permission stack check, check to throw an error without permission, otherwise normal return.

The Doprivilege () method terminates the stack check to get the convenience of checking. Check that the next stop is performed to Doprivilege. If the permissions of the Doprivilege are less than their own, their permissions are lowered to the permissions provided in Doprivilege.

Other

What Java does not solve is that memory is growing, threads are too many to be slow, no mappings for users and permissions (such as UNIX, do not know now).

Security has other problems, such as physical, someone has stolen something, your staff is a spy and so on.

This article transferred from: http://www.cnblogs.com/Y/archive/2011/03/24/JavaVM_Learning_Chapter3_Security.html

Thanks to the author for sharing

Java Virtual machine-insurance sandbox