Sandbox security model, class loading, class File validation, Sandbox class

Sandbox security model, class loading, class File validation, Sandbox class

This article is mainly used for self-learning records. I will not list them one by one based on some blogs on the Internet. Thank you for your selfless dedication.

Compared with C ++, Java has good security. Using Java for development can better reduce the chance of errors. To make Java programs more robust, JAVA provides the following basic components, A security water tank model is formed to provide users with better security and reduce the chance of developers' mistakes:
1. Class Loader Structure
2. class file validator
3. Security Features of built-in JAVA virtual machines
4. Security Manager and JAVA API
The content of each part is displayed:

The box (including the box) contains a sandbox Security Model for JAVA runtime. It should be noted that it is only used to describe what JAVA provides to achieve high security. It does not mean that there is a division of this range in JAVA virtual machines.
Next, I will explain my understanding of each department in sequence. It may be wrong, and I am not very familiar with it.
1. Security Manager and JAVA API
API: JAVA provides a large number of available APIs and ensures that these APIs are trustworthy and malicious. If all JAVA programs we write are completed using JAVA APIs, it is safe for JAVA virtual machines to save programs that use these Apis.
Security Manager:
In the JAVA security mechanism, the security features of the class Loader, class File Checker, and built-in JAVA virtual machine are used to save the integrity of the programs loaded and run by the virtual machine, protect them from malicious or vulnerable code; save as much as possible during the program running without causing memory benefits. When exceptions or errors occur, try to ensure the normal operation of other threads as much as possible (when exceptions occur, they can be thrown without terminating the current thread, when an error occurs, the current thread can be aborted without affecting other threads.
The security manager protects the external resources of virtual machines from malicious or vulnerable code attacks. It defines the external boundaries of the sandbox.
In general, security manager provides an access control policy file for external resources (such as local files) to be accessed. When you access a specified file, enforce custom security policies for security checks.
2. JAVA class loading
In the JAVA sandbox, the class loading system is the first line of defense. After all, the class Loader loads the code (class file)-this Code may be malicious or vulnerable-into the virtual machine.
The dual-parent delegation mechanism is used only when the VM loads the class again.
The installed Java Virtual Machine already contains three class loaders: start class loaders, extended class loaders, and system class loaders. The previous one is followed by the next parent loader. In the design mode, the Child loader acts as the parent loader. The default class file starts searching from the system class loader, however, it may not be the extension class loader or start class loader that finally loads the class, but it seems that the class is loaded by the system class loader.
Bootstrap class loader: it is used to load the core library of Java. It is implemented using native code and does not inherit from java. lang. ClassLoader.
Extensions class loader: used to load Java extension libraries. The Java virtual machine provides an extension library directory (for example, jdk 1.5.0 _ 04 \ jre \ lib \ ext ). This class loader searches for and loads Java classes in this directory.
System class loader: it loads Java classes according to the CLASSPATH of Java applications. Generally, Java application classes are loaded by them. You can obtain it through ClassLoader. getSystemClassLoader.
Of course, you can also implement your own class loaders. developers can inherit the java. lang. ClassLoader class to implement their own class loaders. The parent loader of the Class Loader compiled by developers is the system class loader, which forms the tree structure of the Class Loader:

Agent Mode of the Class Loader
When the class loader tries to find and define the byte code of a class, it will first proxy to its parent class loader, and the parent class loader will first try to load this class, and so on. Before introducing the motives behind the proxy mode, you must first explain how the Java Virtual Machine judges that the two Java classes are the same. The Java virtual machine not only needs to check whether the full name of the class is the same, but also whether the class loader to load this class is the same. Only when the two are the same can the two classes be considered the same. Even for the same byte code, the classes obtained after being loaded by different class loaders are also different. For example, a Java class com. example. Sample is compiled and the byte code file Sample. class is generated. Two different class loaders, ClassLoaderA and ClassLoaderB, read the Sample. Class file and define two java. lang. class instances to represent the Class. The two instances are different. For Java virtual machines, they are different classes. Attempts to assign values to the objects of these two classes will throw a runtime exception ClassCastException
After understanding this, you can understand the design motivation of the proxy mode. The proxy mode is used to ensure the type security of the Java core library. All Java applications must reference at least the java. lang. Object class. That is to say, when running, the java. lang. Object class needs to be loaded into the Java Virtual Machine. If this loading process is completed by the Java application's own class loader, there may be multiple versions of java. lang. Object classes, and these classes are incompatible. In the proxy mode, the class loading of the Java core library is completed by the bootstrap Class Loader. This ensures that all Java applications use classes of the same version of the Java core library, is compatible with each other.

Classloaders and Web containers

For Web applications running in Java EE containers, the implementation of the Class Loader is different from that of General Java applications. Different Web containers are implemented in different ways. For Apache Tomcat, each Web application has a corresponding class loader instance. The Class Loader also uses the proxy mode. The difference is that it first tries to load a class. If it cannot be found, it then acts as a proxy to the parent class loader. This is in the opposite order of the general class loader. This is a recommended practice in the Java Servlet specification, and its purpose is to make the Web application's own class have a higher priority than the class provided by the Web container. An exception to this proxy mode is that the classes in the Java core library are not within the search scope. This is also to ensure the type security of the Java core library.

3. class file validator
Together with the class loader, the class File Checker ensures that the content of the loaded class file has a correct internal structure, and these class files are consistent with each other. If the class file validator finds a problem in the class file, it will throw an exception. A good java compiler should not generate malformed class files, but the java Virtual Machine does not know how a specific class file is created. Because a class file is essentially a byte sequence, the virtual machine cannot tell whether a specific class file is generated by a normal Java compiler or by hackers. Therefore, the implementation of all Java virtual machines must have a class file validator, which can call the class file to ensure the safe use of these defined types.
The class file validator performs its operations through four independent scans.
3.1 first: Structure Check of the class file
During the first scan, for each segment of the byte sequence that will be imported as a type, the class file examiner checks whether it complies with the basic structure of the Java class file. In this scan, the validator will perform many checks. For example, each class file must start with four identical Bytes: Magic number 0 xCAFEBABE. The main purpose of the first scan is to ensure that the byte sequence correctly defines a type, which must comply with the fixed format of the Java class file, in this way, it can be compiled into the internal data structure in the Method Area (based on implementation. The second, third, and fourth scans are not performed on binary data that conforms to the class file format, but on the data structure determined by the implementation in the method area.
3.2 second trip: checks the principles of Data Types
Scanning occurs in the method area, mainly for semantic, lexical and syntax analysis, that is, to check whether this class can be compiled smoothly. In the second scan, the class file examiner does not need to view bytecode or view or load any other types. In this scan, the validator checks each component to see if they belong to the instance type and whether they are structured correctly. For example, the method Descriptor (its return type, and the type and number of parameters) is stored as a string in the class file. The checker checks whether the method descriptor conforms to the specific syntax and the format is correct.
3.3 3rd: bytecode Verification
Bytecode Verification
This verification involves two concepts that are hard to understand. The first is the byte code stream and the second is the stack frame.
When the bytecode is executed, an operation code is executed. the java Virtual Machine constitutes an execution thread, and each thread has its own java stack, which consists of different frame stacks, each method call gets a stack frame of its own.
It would be easier for people who have learned assembly to understand these two concepts.
Byte code stream = operation code + operand, which can be seen here as the pseudo command + operand in the Assembly, because the operation code here is actually the "assembly pseudo command" recognized by jvm ", the concept of operands is not much different from the data types in the Assembly.
Let's take a look at the stack frame. The stack frame is actually quite understandable. The stack frame has a local variable stack and an operand stack. The two memory blocks are different when data is stored, the operand stack is used to store the intermediate results, results, or operations of bytecode command execution. The local variable zone is used to store local variable parameters. This is a good understanding.
The verification process of this bytecode verifies the validity of the bitstream, that is, the legitimacy of the operand + operation code.
 
Java class file encoding is called bytecode because each call of an operation command occupies only one byte. Except for two exceptions, all the operation codes and their operands are aligned in bytes, this makes it more advantageous for byte streams to be less frequently transmitted. These two exceptions are some operation codes, which can be one to three bytes a day between the operation code and their operands, so that the operands are aligned by byte

3.4 Fourth: verification of symbol reference
Because most jvm implementations are delayed loading or dynamic links, delayed loading means that when the jvm loads A class A, if Class A references other Class B, the virtual machine will not load the referenced Class B into the memory at the same time, but will not load it until it is executed.
The expression of the referenced Class B in Class A is mainly registered in the symbol table, the fourth step is to change the referenced Class B's symbolic reference name in the referenced Class A to the direct reference in the memory when the referenced Class B needs to be used.
Therefore, the time of the fourth trip is unpredictable and occurs in the method area. This process is called dynamic connection.
It can be simply divided into two steps.
1. Search for the referenced class (load it if necessary)
2. replace a symbolic reference with a direct reference. For example, a pointer to a class, field, or method can be directly referenced when the referenced class is used next time without loading it.

4. Security Features of built-in JAVA virtual machines
The Java Virtual Machine loads a class and performs a one-to-three-Byte class file test on it. These bytecode can be run. In addition to the symbol reference test (the fourth scan), Java virtual machine also performs some other Security Mechanism operations when executing the bytecode. Most of these mechanisms are provided by JAVA. But it is also a feature of Java virtual machines.
Type-safe reference
Structured access without pointers
Automatic garbage collection
Array boundary check
Null reference check

Java implements the sandbox security requirements through the above security mechanisms.

 

What is the working mechanism of ClassLoader?

Jvm classLoader architecture:
A, Bootstrap ClassLoader/start class loader
It is mainly responsible for packaging the core api under the jdk_home/lib directory or the jar specified by the-Xbootclasspath option.

B. Extension ClassLoader/Extension class loader
It is mainly responsible for packaging the jar package in the jdk_home/lib/ext directory or the jar package in the directory specified by-Djava. ext. dirs.

C, System ClassLoader/System Class Loader
It is mainly responsible for packaging classes and jar files in the directory referred to by java-classpath/-Djava. class. path.

B. User Custom ClassLoader/User-defined class loader (subclass of java. lang. ClassLoader)
During the program running, the class file is dynamically loaded using the subclass of java. lang. ClassLoader, reflecting the Dynamic Real-time class loading feature of java.

Classloader features:
1. Each ClassLoader maintains its own namespace. Two classes with the same name cannot appear in the same namespace.
2. To implement the Class Loader security mechanism at the top layer of the java Security Sandbox Model, java adopts the "parent-parent delegated load chain" structure by default.
For example:
Class digoal:
In the class diagram, BootstrapClassLoader is a separate java class. In fact, it should not be called a java class here.
Because it does not need java implementation at all.

It is constructed at jvm startup and is responsible for the core library of the java platform. (As described above)
 
the powerful Security Mode sandbox technology of the security browser is really useful,

I personally think that, since it is known as a secure browser, security should be the first priority. It is proposed that the browser should be enabled by default in a super safe mode, you can set the strong security mode to the default startup mode at least during installation or configuration.

Now, it is uncomfortable to open the link in Normal Mode every time. Although the official saying that the normal mode is safe, if you want to say so, I 'd better use IE + security guard.

I hope the official website will pay attention to this suggestion. If the next version still does not pay attention to it, I can only uninstall it with regret.