Summary: Java's security structure - 4 components of the "sandbox" model: built-in security feature of Java virtual machines and languages, type load structure, class file verifier, security manager, and Java API. Keywords: Java language security sandbox structure
The Java security model is different from traditional security methods. In traditional security methods, most operating systems allow applications to fully access system resources, in which the operating environment does not provide security machines, the operating environment cannot be trusted. To make up for this defect, the security policy often requires the establishment of trust before the application executes, for example, requiring programmers to check the unsafe code in the virus and source code before performing applications from the Internet. This approach has 2 questions: (1) Determine if the program is safe and is very wasteful, very waste time, very few programmers will spend the source code of the program, then compile it cost the machine code to ensure the program is safe. (2) Virus checks should be maintained to ensure effectiveness. Java's security model is different. In order to prevent the user system from being damaged by the unsafe procedures downloaded through the network, Java provides a "sandbox" that can run the Java program inside. Java's security model makes Java a technology suitable for network environments. Java security allows users to introduce or run the applet from the Internet or intranet, and Applets are restricted to its "sandbox", and Applet can do anything in the sandbox, but cannot read or modify any data outside the sandbox. The sandbox can prohibit many activities of unsafe procedures, such as: 1. Read and write the hard drive. 2. Network connection with other hosts (hosts that do not include the program). 3. Create 1 new process. 4. Load 1 new dynamic library and call local methods directly. The thinking of the "sandbox" model is to run untrusted code in the trusted environment, so even if the user is not careful to introduce unsafe APPLET, Applet does not damage the system.
1 "sandbox" model
The "sandbox" security model is built in the Java structure, which is mainly composed of the following parts: 1. Built in the Java virtual machine and the language security feature. 2. Load structure of class. 3. Class file verifier. 4. Security Manager and Java API. The following is set forth below.
1.1 Security feature in Java virtual machines and languages The Java language has some mechanisms that make the Java program very stable. These mechanisms are also characteristics of Java Virtual Machine (JVM), which are: 1. Safety type conversion. In C, C , you can convert any type conversion by a pointer, but often brings unsafe, and in Java, the runtime system will perform type compatibility check to prevent unsafe conversion. 2. No pointer. The pointers are the most flexible in C and C , and the most prone to erroneous data types are also possible. Memory address operations made by the pointer often cause unpredictable errors, and after the display type conversion is performed for a memory address, the private member in 1 C can be accessed to destroy the security, causing the crash of the system. Java completely controls the pointer, the programmer does not directly carry out any pointer operation. 3. Automatic garbage collection. In C, the programmer allocates and releases memory through library functions Malloc () and Free (), and C is assigned and released by operator New and Delete. Release the released memory block or unassigned memory block, it will cause the system's crash; the same, forget the memory block that is no longer used will gradually exhaust system resources. In Java, all data structures are objects, and allocate the memory reactors through the operator NEW. Get the object's processing, while the memory actually assigned to the object changes, and Java automatically manages and collects garbage collection, effectively preventing errors caused by programmers, and more Hello use of system resources. 4. Array boundary check. If there are array access in the program, the JVM checks if the array access is off, thereby preventing errors caused by the array of crosses. 5. Check NULL references. If the reference is used as NULL, JVM will throw 1 exception.
1.2 Class loader structure type loader structure has played an important role in the sandbox model. In a virtual machine, class loader is responsible for introducing, defining binary data for the class and interface of the runner. There may be more than 1 type loader in the virtual machine. 1 Java program can use two types of class loaders: the original class loader and class loader object. The original class loader is a 1 part of the JVM, which typically loads a secure class from the local hard drive, including the Java API class. When running, the Java application install class loader object, class loader objects are written in Java language, after compiling into clause files, loaded into virtual machines, initialized like other objects. Class loader objects are used to load classes in a custom manner, such as downloaded class files over the network. The JVM is considered secure by any classes loaded through the original class loader, regardless of whether this class is a Java API. The class that will be loaded by the type of loader object is considered suspected, and it is not safe to default by default. Java's structure can create multiple namespaces in one application, and the namespace is a collection of class names loaded by 1 specific class loader. JVM maintains 1 namespace for each class loader, this namespace has all the names of all classes loaded by that class loader. These classes cannot be accessed from each other in different namespaces, and these classes cannot be accessed directly from different types of loads. When writing a program, you can put a different type of source in different namespaces. In this way, you can use Java class loader structure to control the interaction between different code, you can prevent unsafe code access. Destroy the security code. For Applet, the same reason, by placing an applet class file from the source in different namespaces, preventing unsafe codes from damaging the security code. In the "sandbox" structure, the class loader structure is to prevent the first wall of unsafe code, and its main two aspects: 1. Prevent unsafe code access, destroy the security code. 2. Prevent unsafe code pretend to be safe. This 2 is implemented by the following method: 1. Put the code in multiple namespaces and set "barrier" between the code of different namespaces. The class loader structure is to prevent unsafe code access by namespace, and destroy the security code. A "barrier" is set between the namespace that is loaded into a class in different namespaces. In JVM, classes in the same namespace can directly interact, and classes in different namespaces cannot detect the existence of the other party, unless the program allows them to interact. 2. Protect the boundary of the trusted class library (like the Java API). If the class load is loaded into 1 class, this class is to pretend to be 1 part of the Java API (for example, class name java.lang.virus), and the class loader will transfer the request to the original class load. If the original type loader cannot load this class, the class loader throws the security exception and refuses to load this class.
1.3 Class File Checkr Each JVM has 1 class file verifier to ensure that the loaded class file has the correct internal structure. If the class file verifier finds an error, it throws 1 exception. Class file verifiers can help check if the class is safe. Because class files are composed of binary data, JVM does not know if this class file is generated by hackers, whether it may damage the integrity of the virtual machine, so the virtual machine is important to verify the introduced bytecode. The process of class file verifier verification can be divided into two phases: Phase 1 happens after the class is just loaded, the class file verifier checks the internal structure of the class file, including the integrity of the bytecode included in the verification. Phase 2 occurs when the byte code is executed, the bytecode verifier determines whether the class, domain, and method exists in the symbol reference. 1.3.1 Internal inspection At stage 1, the class file verifier checks if the file is correct, whether the internal is consistent, whether it follows the Limit of the Java programming language, whether the byte code is executed by JVM, if the class file verification Check an error, it will throw 1 error, and class files are no longer used by programs. 1. Check the format and internal consistency at the stage 1. In addition to checking the integrity of the bytecode, check the format and internal consistency of the class file. For example, each class file must begin with the same 4-byte number 0xcafebase, the first thing to check by such file verifiers is whether the introduced file is starting with 0xcafebase. The class file verifier is also equal to whether the length of the class file is consistent with the length recorded in the class file, that is, whether the check class file is complete, whether it is taken part or is added. The class file verifier also checks if the classes follow the Java language regulations. If all classes must have 1 parent class, except for the Object class. 2. Byte Code Checkout Once the class file verifier successfully completed the format and internal consistency check, the bytecode is started to verify. By data stream analysis of the byte stream representative method, whether the operation code is effective and the operation code has a valid operand, etc. to verify that the bytecode stream can be executed by the virtual machine. 1.3.2 The check symbol reference for the symbol reference is a string of the name of the reference item and other information, which is sufficient to use to classify, domain, or methods. The verification reference to the symbol is validated whether the reference is valid, if the reference is invalid (for example, if the class is not loaded, or the class or method exists but does not contain the domain or method to reference, the class file verifier will throw 1 error. . 1.4 Security Manager and Java API Security Manager define the exterior boundaries of "sandbox". Security Manager is a subclass of class java.lang.securityManager, which is customized. In the Java API class, when taking some actions, the Security Manager typically requires security managers to check if this action is secure, including: 1. Accepting a Socket connection from a particular host. 2. Modify the thread (change thread priority, end thread, etc.). 3. Open the Socket connection for a particular host. 4. Create 1 new class loader. 5. Delete a specific file. 6. Create a new process. 7. Program exits. 8. Call dynamic libraries containing local methods. 9. Wait for a connection. 10. Enter the class from a specific package. 11. Add 1 new class to a specific package. 12. Access or modify system features. 13. Access to specific system features. 14. Read the file. 15. Write a file. Since the security manager needs to be checked before performing the above action, the Java API does not perform any action prohibited by the security measures established by the Security Manager. Java API performs 1 process that may not safely, usually divided into 2 steps: First, the Java API code checks if the security manager is installed.
If there is no installation, you cannot perform step 2's check, then execute a code that may not safely; if you install, continue to perform step 2's check, call the appropriate check method in Security Manager to check the action, if The action is prohibited, and the inspection method throws 1 safety exception, no insecure activities; if the action is allowed, the check method returns, the Java API method continues to perform the action. 2 Conclusion
The safety reliability is proportional to the expense. The higher the safety, the higher the cost of safe payment, so the safety reliability is not, the higher the better, and should be equivalent to the value of the protected information. The security policy of the computer or network should be multifaceted, only one "sandbox" of the downloaded Java code is not enough, and should include security, machine, etc., such as whether the machine is set, whether the employee is It is a commercial spy. However, the advantage of the Java security model is that once it is established, you can do a lot of things for programmers. Programmers don't have to worry about whether the program is safe, and Java's security structure has been determined if the program is safe. If the code is not safe, use "sandbox" The structure can protect information from damage.
