Document directory
- "Parent assignment class Loading Model" that plays the first security protection role"
Security Model Overview
The security model makes Java A technology in the network environment because it establishes a necessary credibility mechanism for secure execution of network mobile code.
The Java security model focuses on protecting end users from network downloads, unreliable sources, and malicious programs. The Sandbox mechanism becomes a support mechanism for this purpose, and stores untrusted Java programs in the sandbox. The Sandbox restricts the activities of unreliable programs. programs can do anything within the security boundary of the sandbox, but cannot do anything that spans these boundary.
For example, the sandbox in version 1.0 imposes the following restrictions on many unreliable applets:
A. Read and Write local disks
B. Perform any network connection, but cannot connect to the source host that provides this applet
C. Create a new one.
D. Load a new dynamic link library
However, the Sandbox Model Based on version 1.0 is too strict, and some malicious (but unreliable) code often cannot work effectively. Therefore, in Version 1.1, the "sandbox" model is improved and a trust model based on code signature and authentication is introduced.
Basic sandbox
The basic components of the Java sandbox include:
1. Class Loader Structure
2. Class file validator
3. Security features built into Java virtual machines
4. Security Manager and Java API
The most important feature is that the class loaders and security managers in the components can be customized by users.
The "parent delegate class Loading Model" that acts as the first security guarantee indicates that the parent delegate class loading takes priority from starting the class loader at the top layer, load the class model in the top-down mode (see the First Class Loader architecture ).
The advantage of this model is that the classes loaded by the underlying classloader cannot be called with the classes loaded by the top classloader.
Even classes in the same package are isolated as long as they do not belong to the same class loader. This has played a role in security isolation for some categories with security risks. So that it cannot pretend to be a system class to disrupt the normal operation of the program.
In addition, different class loaders also have their own class loading range. For example, when the class loader is started, it only installs packages/classes in the JDK/lib directory. Therefore, system-level classes are relatively secure. The class file validators use four scans to ensure that the class file is correct. First, when the class is loaded, check whether the structure of the class file is correct. Typically, check whether the class file is headed by oxcafebabe. Through this check, you can filter out most files that may be damaged or are not class files at all to pretend to be loaded. The second step is to perform a semantic check called type data during the connection process to check whether it complies with the compilation rules in the Java language features. For example, if the superclass of a class is not an object, an exception is thrown. Check whether each method descriptor conforms to a specific syntax and format. The third step is to perform bytecode verification during the connection process and check whether the bytecode can be safely executed by JVM without causing JVM crash.
The byte code stream represents the Java method. It is a sequence composed of single-byte commands called operation codes. Each operation code is followed by one or more operands.The operands are used to provide the required additional data when the Java virtual machine executes the operation code command. When the bytecode is executed, each operation code is executed in sequence, which constitutes the execution thread in the Java Virtual Machine. Each thread is granted its own java stack, which consists of different stack frames. Each method call will get a stack frame (that is, a method corresponds to a stack frame). The stack frame is actually a memory segment, the local variables in the method and the intermediate results of calculation are stored. The part used to store the intermediate results of a method is called the method's operand stack. When executing an operation code, in addition to using the followed operand, the virtual machine can also use data in the operand stack or data in local variables. The fourth step is symbol reference verification. A class file that contains the full name and descriptor of other classes referenced by it and creates a symbolic reference with them (a virtual, non-physical connection ). When the program runs at the location where the symbolic reference is required for the first time, the JVM checks the correctness of the symbolic link and then establishes a real physical reference (direct reference ). Because the fourth scan must check other classes than the class file to be detected, this scan may need to load new classes.
Dynamic connection resolves a symbolic reference to a direct reference.When the Java virtual machine executes the bytecode, if it encounters an operation code, this operation code will be referenced by a symbol pointing to another class for the first time, then the virtual machine must parse this symbol reference. During parsing, the virtual machine executes two basic tasks: 1. Search for the referenced class (load it if necessary ). 2. replace a symbolic reference with a direct reference, for example, a pointer or offset pointing to a class, field, or method. JVM type security features are basic Java language features, which reduce the chance of memory confusion and crashes in Java programs.
- Structured memory access (without pointers, hackers cannot tamper with memory data to a certain extent)
- Automatic garbage collection
- Array boundary check
- Null reference check
- Data Type Security
Java API Security Manager securitymanager is the closest to our programmers in the security sandbox. Securitymananger is an API-level, customizable Security Policy Manager that goes deep into Java APIs and can be seen everywhere. For example, securityclassloader. By default, the Java application does not set the securitymanager instance (which means the security check is not performed). This instance needs to be set through system. setsecuritymanager when the program starts. Generally, the permission check is done through securitymanager. checkpermission (permission perm. An external program creates a permission instance and passes it to the previous check. Permission is an abstract class that must be inherited for different permission verification. For example, filepermission indicates the read and write permissions on a file. New filepermission ("test.txt", "read") You can throw this instance to securitymanagerand check that the handler can read the text.txt file. Java signature/certificate mechanism ensures that users can securely call external jar files to prevent your trusted jar files from being tampered. First, the Java signature must be based on the jar package. That is to say, you must package the class you want to provide into the jar. Then, use the Java signing tool (jarsigner) to sign and publish the jar package. Signature principle: an asymmetric algorithm is used to generate a pair of public and private keys.
Certificate
The certificate is based on the signature, and the signature value is further encrypted. The private key and public key used for this encryption are provided by the certificate authority.
This method is used to prevent malicious users from having to manipulate the public key before it is sent to you, and then send a jar file with hands and feet to you, you can unlock the jar package that has been moved by using the public key. After a certificate is used, it encrypts the encrypted signature value. In this way, you only need to use the public key of the Certificate Authority to decrypt it, then, use the public key of the publisher of the jar package to decrypt it. (Only to a certain extent, to provide some security)
