Would a blank Java security policy file be the most restrictive?

Question

I am creating an application that allows users to execute uploaded Java files. I am trying to restrict what they can do with a Security Manager. Would a blank policy file be the most restrictive, not allowing them to do as much as possible? Would this restrict them from doing anything basic that I shouldn't be restricting them from?

Answer 1

Yes, a security policy that grants no permissions is the most restrictive policy you can define with the standard Java Security Manager, and would prevent any code running in that JVM from doing anything that requires a security permission. The Java core API's generally check some variety of security permission before allowing code running under a Security Manager from doing anything that could be harmful, so in theory it's safe to run untrusted code where no permissions have been granted.

There are some exceptions: for example code loaded from the system classpath is allowed to call System.exit(), which would stop your application, and code running with no permissions can still create any number of new threads, which could lock up the system. If these are concerns you'll need to consider writing a custom Security Manager.

In your case if you're running your application code and user-provided code in the same JVM, you'll need to give your application code permission to do the things it needs to do while granting no permissions to untrusted code, so you would need to add something like the following to your policy file:

grant codeBase "file:path/to/trusted/application/jars" {
  permission java.security.AllPermission;
};

Be aware that if you're specifying the policy file on the command line you'll need to use a double equals (e.g. -Djava.security.policy**==**policy.file ), otherwise your policy will extend the default Java security policy, which grants a minimal set of permissions to all code.