Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

[Doug Simon]

> On 26 Jan 2017, at 03:32, Mandy Chung <mandy.ch...@oracle.com> wrote:
> 
> (dropping jdk9-dev.  security-libs is the appropriate list to review security 
> permission)
> 
>> On Jan 23, 2017, at 1:56 PM, Doug Simon <doug.si...@oracle.com> wrote:
>> 
>> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a 
>> security manager is present. Since neither of these modules is accessible to 
>> application code, it should be ok to give them all permissions. This seems 
>> to be the approach for a number of other modules including 
>> jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this 
>> small change that configures this proposed permission level.
>> 
>> http://cr.openjdk.java.net/~dnsimon/8145337/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8145337
> 
> jdk.vm.compiler is defined by the application class loader and it’s used by 
> AOT tool.  I wonder why it has to run with security manager.

Without java.security.AllPermission, the policy for jdk.vm.compiler required to 
get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions 
-Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is 
show below (annotated with comments denoting the methods requiring the 
permissions):

grant codeBase "jrt:/jdk.vm.compiler" {
    // org.graalvm.compiler.hotspot.HotSpotGraalJVMCIServiceLocator.<init>
    permission jdk.vm.ci.services.JVMCIPermission;

    // 
org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties
    permission java.lang.RuntimePermission 
"accessClassInPackage.jdk.internal.misc";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

    // org.graalvm.compiler.core.common.util.ModuleAPI.<clinit>
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission 
"accessClassInPackage.jdk.internal.module";

    // org.graalvm.compiler.options.OptionValue.<clinit>
    permission java.util.PropertyPermission "graal.profileOptionValue", "read";

    // org.graalvm.compiler.debug.Debug.<clinit>
    permission java.util.PropertyPermission "*", "read,write";

    // org.graalvm.compiler.core.common.UnsafeAccess.initUnsafe
    permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";

    // org.graalvm.compiler.hotspot.BootstrapWatchDog.<init>
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";

    // org.graalvm.compiler.hotspot.replacements.SHA2Substitutions.<clinit>
    permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.provider";

    // 
org.graalvm.compiler.nodes.graphbuilderconf.InvocationPlugins.resolveClass
    permission java.lang.RuntimePermission 
"accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission 
"accessClassInPackage.oracle.jrockit.jfr.jdkevents";
};

There’s no guarantee that this is all the permissions required since not all 
code paths are exercised during bootstrap.

>  You can reference JDK tools such as jdk.compiler and jdk.jlink that are not 
> granted with any permission.

Neither of those tools create code and install it in the VM. I don’t think a 
fine grained SecurityManager policy makes sense for a VM compiler since it 
could subvert security by compiling/installing malicious code. That is, a VM 
compiler has to be a trusted component. Keep in mind that user code cannot get 
to jdk.vm.compiler.

For comparison, below are all the modules currently given 
java.security.AllPermission by lib/security/default.policy:

grant codeBase "jrt:/java.activation" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.compiler" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.corba" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.incubator.httpclient" {
};

grant codeBase "jrt:/java.scripting" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.security.jgss" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.sql" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/java.sql.rowset" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.dynalink" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.internal.le" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.jsobject" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.naming.dns" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.scripting.nashorn" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.scripting.nashorn.shell" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.security.auth" {
    permission java.security.AllPermission;
};

grant codeBase "jrt:/jdk.security.jgss" {
    permission java.security.AllPermission;
};