Introduction to Java sandbox mechanism principles

Programmers write a Java program. By default, you can access any machine resources, such as reading and deleting some files or network operations. When you deploy a program on a formal server and the System Administrator is responsible for the security of the server, he may not be sure whether your program will access resources that are not supposed to be accessed, to eliminate potential security risks, you may have two methods: 1. Run your program under an account with limited permissions;
2. Use the Java sandbox mechanism to limit your program. Here we will talk about the latter method.

How to set a "sandbox" for a program? This setting should avoid modifying the program code and is easy to use. According to the Java documentation, we understand that there are only two simple steps.

Step 1. Add a running parameter to run a program in the sandbox:
Java-Djava. security. manager-jar myapp. jar

Step 2. Set specific permissions, such as creating your own policy file myapp. policy:
Grant codeBase "file :$ {user. dir}/myapp. jar "{

Permission java. io. FilePermission "$ {user. dir }$ {/} *", "read ";

};

This setting means that the Code loaded from myapp. jar has the "read" permission on all files in the current directory.

After completing these two steps, run the following command:
Java-Djava. security. manager-Djava. security. policy = myapp. policy-jar myapp. jar

You can ensure that the program only has the permissions you specified. When accessing other resources, an exception similar to "access denied" is thrown. The default policy file is $ {java. home}/jre/lib/security/java. policy. It has very few permissions and has nothing to do with accessing system resources.

Then the question arises, how is all this achieved? Where is the checked code? who developed the code?

The answer is: this is what SUN did. SUN has inserted the code of these checks into all the APIs that access system resources.

For example:
BufferedReader br = new BufferedReader (new FileReader (fileName ));
String line = br. readLine ();

When you run to the first line and continue debugging into the Java API source code, you can encounter the following code:

SecurityManager security = System. getSecurityManager ();
If (security! = Null ){
Security. checkRead (name );
}

The code here indicates that if SecurityManager is installed, the security check is performed (whether the file has read permission ). When you add the running parameter Djava. security. manager, The SecurityManager is installed. This corresponds to the first step above.

Continue debugging and see the following code:
CheckPermission (new FilePermission (file,
SecurityConstants. FILE_READ_ACTION ));

Obviously, this corresponds to the second step above. FilePermission is java. io. FilePermission, and FILE_READ_ACTION is "read ".
So what does codeBase correspond?

CodeBase involves ClassLoader knowledge. In short, when ClassLoader loads some code, it saves the code source information, which is combined with the Information read from the policy file, the system can make the decision.

Details are always complex, but after understanding this principle, in-depth details can play a leading role. The most confusing thing here is not the configuration and rules of the policy file, but who is making decisions and when. Someone may ask a question. If I don't use SUN's API and I write some code to access resources on the machine, can I bypass the "sandbox? Theoretically, this is acceptable, but as long as you write Java code and still use SUN's virtual machine, you do not have this opportunity. SUN's class loader mechanism ensures that you cannot replace or interfere with its core class libraries.

This article from the CSDN blog, reprinted please indicate the source: aspx "> http://blog.csdn.net/kevinkevin/archive/2010/12/04/6054980.aspx