Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "what is the security sandbox mechanism of Java applications?", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this article "what is the security sandbox mechanism of Java applications?"

If you read the source code often, you will find that the source code of Java is full of code similar to the following

Class File {

/ / determine whether a disk file exists

Public boolean exists () {

SecurityManager security = System.getSecurityManager ()

If (security! = null) {

Security.checkRead (path)

}

...

}

}

This is obviously a security check code to check whether you have access to the disk path. Why does the Java language need such security check code? Let's take a look at the connect function source code of the client socket, which needs to check whether the user has permission to connect a network address.

Class Socket {

Public void connect (SocketAddress endpoint, int timeout) {

...

SecurityManager security = System.getSecurityManager ()

If (security! = null) {

If (epoint.isUnresolved ())

Security.checkConnect (epoint.getHostName (), port)

Else

Security.checkConnect (addr.getHostAddress (), port)

}

}

...

}

}

Then look at the source code of the server socket, which checks the listening permissions of the port.

Class ServerSocket {

Public void bind (SocketAddress endpoint, int backlog) {

...

SecurityManager security = System.getSecurityManager ()

If (security! = null)

Security.checkListen (epoint.getPort ())

...

}

}

It seems that all method calls related to IO operations require a security check. The permission checking associated with IO operations seems understandable that not all IO resource user processes are accessible at will. But even environment variables are not allowed to be read at will, and not all environment variables are limited, but a specific environment variable, isn't this security check a bit too much?

Class System {

Public static String getenv (String name) {

SecurityManager sm = getSecurityManager ()

If (sm! = null) {

Sm.checkPermission (new RuntimePermission ("getenv." + name))

}

Return ProcessEnvironment.getenv (name)

}

}

This is because the security check manager of Java and the permission check of the operating system are not a concept. Java not only writes server applications, it can also run on the browser as a client (Applet), it can also run on the phone in the form of app (J2ME), JVM for different platforms will use different security policies. For Applet, the restrictions are particularly severe, and Applet is usually not allowed to manipulate local files. When the specific IO operation is performed after the security check of Java is passed, the operating system will continue to check permissions.

When we run java programs locally, we usually do not open the security checker by default. We need to execute the jvm parameter to open it.

$java-Djava.security.manager xxx

$java-Djava.security.manager-DDjava.security.policy= "${policypath}"

Because security restrictions can be customized, you also need to provide a specific security policy file path. The default policy file path is JAVA_HOME/jre/lib/security/java.policy. Let's take a look at what is written in this file.

/ / built-in extended library authorization rules

/ / indicates that the class libraries in the JAVA_HOME/jre/lib/ext/ directory have full access to any resources.

/ / including javax.swing.*, javax.xml.*, javax.crypto.* and so on

Grant codeBase "file:$ {{java.ext.dirs}} / *" {

Permission java.security.AllPermission

}

/ / other class library authorization rules

Grant {

/ / allow threads to commit suicide by calling their own stop method

Permission java.lang.RuntimePermission "stopThread"

/ / allow programs to listen on randomly available ports of localhost, and do not customize ports at will

Permission java.net.SocketPermission "localhost:0", "listen"

/ / restrict access to system attributes. The following series of configurations are only allowed to read some built-in attributes.

Permission java.util.PropertyPermission "java.version", "read"

Permission java.util.PropertyPermission "java.vendor", "read"

Permission java.util.PropertyPermission "java.vendor.url", "read"

Permission java.util.PropertyPermission "java.class.version", "read"

Permission java.util.PropertyPermission "os.name", "read"

Permission java.util.PropertyPermission "os.version", "read"

Permission java.util.PropertyPermission "os.arch", "read"

Permission java.util.PropertyPermission "file.separator", "read"

Permission java.util.PropertyPermission "path.separator", "read"

Permission java.util.PropertyPermission "line.separator", "read"

Permission java.util.PropertyPermission "java.specification.version", "read"

Permission java.util.PropertyPermission "java.specification.vendor", "read"

Permission java.util.PropertyPermission "java.specification.name", "read"

Permission java.util.PropertyPermission "java.vm.specification.version", "read"

Permission java.util.PropertyPermission "java.vm.specification.vendor", "read"

Permission java.util.PropertyPermission "java.vm.specification.name", "read"

Permission java.util.PropertyPermission "java.vm.version", "read"

Permission java.util.PropertyPermission "java.vm.vendor", "read"

Permission java.util.PropertyPermission "java.vm.name", "read"

}

If grant provides the codeBase parameter, it configures permission rules for specific class libraries, and if codeBase is not specified, it is configured for all other class libraries.

If the security check fails, a java.security.AccessControlException exception will be thrown. Even if the security check passes, the permission check of the operating system may still fail, and other types of exceptions will be thrown.

The authorization rules are whitelisted, and the above configuration means that JVM with the default security policy enabled will not be able to access local files. If you need to access local files, you can add the following rules

Permission java.io.FilePermission "/ etc/passwd", "read"

Permission java.io.FilePermission "/ etc/shadow", "read,write"

Permission java.io.FilePermission "/ xyz", "read,write,delete"

/ / allow all files to be read

Permission java.io.FilePermission "*", "read"

The configuration parameters of Permission correspond to its constructor parameters.

Public FilePermission (String path, String actions) {

Super (path)

Init (getMask (actions))

}

Java default security rules are divided into several modules, each of which has its own configuration parameters

Where AllPermission means to turn on all permissions. There is also an uninvited HibernatePermission, which is not a built-in permission module, it is customized for itself by the Hibernate framework, which means that security rules support custom extensions. The extension is also very simple, you can write a Permission subclass and implement its four abstract methods.

Abstract class Permission {

/ / permission name, which is the file name for the file and the socket address for the socket

/ / its meaning is customizable for subclasses.

Private String name

/ / whether other permissions are implied in the current permission object

/ / for example, this method of AllPermission always returns true

Public abstract boolean implies (Permission other)

/ / equals and hashcode are used to compare permissions

Public abstract boolean equals (Object obj)

Public abstract int hashCode ()

/ / permission options read,write,xxx

Public abstract String getActions ()

}

Class CustomPermission extends Permission {

Private String actions

CustomPermission (string name, string actions) {

Super (name)

This.actions = actions

}

...

}

When JVM starts, the permission rules defined in profile will be loaded into the permission pool. The user program uses the permission pool in a specific API method to determine whether the permission to call the API is included, and finally calls the implies method of each permission object in the permission pool to determine whether the specified permission is available.

Class CustomAPI {

Public void someMethod () {

SecurityManager sec = System.getSecurityManager ()

If (sec! = null) {

Sec.CheckPermission (new CustomPermission ("xname", "xactions"))

}

...

}

}

Enabling security check will reduce the execution efficiency of the program. If there are a lot of permission rules defined in profile, the check efficiency will be very slow, so pay attention to the security check and use it sparingly.

There are a lot of security checkpoints in sandboxes. Here are some common scenarios.

File operation

Socket operation

Threads and thread groups

Class loader control

Reflection control

Thread stack information acquisition

Network agent control

Cookie read and write control

If your server program turns on the security check, you need to open a lot of security settings in the policy configuration file, which is very tedious and too much configuration, and the performance check will cause some wear and tear. This is similar to the application permission setting of Android, where a series of application sub-permissions need to be listed in the configuration file of each Android application. However, writing server programs in Java does not seem to be necessary to turn on security checks.

The above is the content of this article on "what is the security sandbox mechanism of Java applications". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.