Subj : Re: [Rhino] security policy
To   : Jo <jo99_fr@yahoo.fr>
From : Igor Bukanov <igor@icesoft.com>
Date : Thu Mar 13 2003 11:55 am

Jo wrote:
> I tried it but unfortunately it doesn't solve my problem. I reproduce it 
> with Rhino Shell. For example create a rhino.policy file with:
> 
> grant codeBase "file:/d:/rhino1_5r4/js.jar" {
>   permission java.lang.RuntimePermission "createClassLoader";
>   permission java.lang.RuntimePermission "accessDeclaredMembers";
>   permission java.io.FilePermission "<<ALL FILES>>", "read";
>   permission java.util.PropertyPermission "*", "read";
> };
> 
> then a test.js file with:
> 
> importPackage(Packages.java.io);
> importPackage(Packages.java.lang);
> new Integer(2);
> 
> run the following command:
> 
> D:\rhino1_5R4>java -Djava.security.manager 
> -Djava.security.policy=rhino.policy -Drhino.use_java_policy_security 
> -jar js.jar test.js
> 
> and you will get a security exception (can't create classLoader) even if 
> the script itself doesn't call the forbidden method (but Rhino which is 
> authorized called it).
> 
> Did I miss something?


I think your trouble comes from the fact that JavaPolicySecurity does 
not put creation of class loader code inside 
AccessController.doPrivileged block. If you replace:

     public GeneratedClassLoader
     createClassLoader(ClassLoader parentLoader, Object securityDomain) {
         ProtectionDomain domain = (ProtectionDomain)securityDomain;
         return new Loader(parentLoader, domain);
     }

there by

     public GeneratedClassLoader
     createClassLoader(ClassLoader parentLoader, Object securityDomain) {
         final ProtectionDomain domain = (ProtectionDomain)securityDomain;
         return (Loader)AccessController.doPrivileged(
             new PrivilegedExceptionAction() {
                 public Object run() { return new Loader(parentLoader, 
domain); }
             }
         });
     }

it should help. The trouble is that it opens a potential security risk 
if a hostile script manages somehow to get a reference to an instance of 
JavaPolicySecurity since then it will be able to create a class loader 
which means it can gain ANY permission due to JDK bugs.

Potentially less troubled way to resolve it is to disable invoker 
optimization which generates a special classes to avoid using 
reflection. You can do it by removing 
org.mozilla.javascript.optimizer.InvokerImpl.class from your Rhino 
distribution. Under JDK 1.4 this optimization may not worth troubles in 
any case.

Regards, Igor

.