4 Replies Latest reply on Jun 11, 2004 2:56 PM by Scott Stark

    Running JBoss with the default sandbox

    Flush Newbie

      Hi, I'm studying Java Security, and trying to run JBoss with the default sandbox parameters.

      I set several permissions so far, and now I'm getting the following exception:


      java.security.AccessControlException: access denied javax.management.MBeanServerPermission: name=createMBeanServer
      at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
      at java.security.AccessController.checkPermission(AccessController.java:401)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
      at javax.management.MBeanServerFactory.checkPermission(MBeanServerFactory.java:189)
      at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:79)
      at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:327)


      Which sandbox permission should I set?

      I've tried setting the Runtime Permission name = "accessClassInPackage.javax." or "accessClassInPackage.createMBeanServer" or "createMBeanServer" withouth success.

      Any help would be appreciated.

      Marco

        • 1. Re: Running JBoss with the default sandbox
          Scott Stark Master

          I did some work in 3.2.4 to better isolate code that should be running as trusted jboss code (provided you mark it as trusted) from untrusted application component code. There were a number of places where trusted operations were running at the privilege level of the caller rather than that of the jboss codebase. A sample policy file I was using with testing when all user code was deployed in a secondary user-deploy directory was:

          [starksm@banshee9100 buildmagic]$ cat /tmp/server.policy
          // The Java2 security policy for the securitymgr tests
          // Install with -Djava.security.policy==server.policy
          // and -Djboss.home.dir=path_to_jboss_distribution and
          // -Djboss.server.home.dir=path_to_jboss_server_config
          
          // Trusted core Java code
          grant codeBase "file:${java.home}/lib/ext/-" {
           permission java.security.AllPermission;
          };
          grant codeBase "file:/C:/usr/java/j2sdk1.4.2_04/lib/*" {
           permission java.security.AllPermission;
          };
          
          // Trusted core Jboss code
          grant codeBase "file:${jboss.home.dir}/bin/-" {
           permission java.security.AllPermission;
          };
          grant codeBase "file:${jboss.home.dir}/lib/-" {
           permission java.security.AllPermission;
          };
          grant codeBase "file:${jboss.server.home.dir}/lib/-" {
           permission java.security.AllPermission;
          };
          grant codeBase "file:${jboss.server.home.dir}/deploy/-" {
           permission java.security.AllPermission;
          };
          
          // Minimal permissions are allowed to everyone else
          grant {
           permission java.util.PropertyPermission "*", "read";
           permission java.lang.RuntimePermission "queuePrintJob";
           permission java.net.SocketPermission "*", "connect";
           permission javax.management.MBeanServerPermission "findMBeanServer";
          };
          


          You could work on further fine tunning the AllPermission granted to jboss code to the minimum needed for various usage scenarios.


          • 2. Re: Running JBoss with the default sandbox
            Flush Newbie

            Scott, I took example from your policy file, with few differences. I'm trying to rely on the default security mechanism that the security model follows in order to find the security policy of an application, that is the intersection between the ${java.home}/jre/lib/security.policy and ${user.home}/.java.policy files. Since I don't want to change the policy file under ${java.home}, I'm trying to configure the user's policy file in order to run JBoss. For this reason, I don't specify the property
            -Djava.security.policy==server.policy as suggested (is this a mistake? If so, why?). The only thing I do, I install the security manager in the run.bat file.

            This is the current user's policy file:

            /* AUTOMATICALLY GENERATED ON Mon Jun 07 22:14:27 BST 2004*/
            /* DO NOT EDIT */
            
            keystore ".keystore";
            
            grant codeBase "file:${java.home}/lib/ext/-" {
             permission java.security.AllPermission;
            };
            
            grant codeBase "file:${java.home}/lib/*" {
             permission java.security.AllPermission;
            };
            
            grant codeBase "file:${jboss.home.dir}/-" {
             permission java.io.FilePermission "D:\\OPENSOURCES\\jboss-snapshot\\-", "read, write, delete, execute";
             permission java.lang.RuntimePermission "*";
             permission javax.security.auth.AuthPermission "createLoginContext.HsqlDbRealm";
             permission java.util.PropertyPermission "axis.EngineConfigFactory", "read, write";
             permission java.util.PropertyPermission "catalina.*", "read, write";
             permission java.io.FilePermission "D:\\J2SE\\jre\\lib\\castor.properties", "read";
             permission java.net.SocketPermission "localhost:1024-", "accept, resolve";
            };
            
            grant codeBase "file:${jboss.home.dir}/bin/-" {
             permission java.security.AllPermission;
            };
            
            grant codeBase "file:${jboss.home.dir}/lib/-" {
             permission java.security.AllPermission;
            };
            
            grant codeBase "file:${jboss.server.home.dir}/lib/-" {
             permission java.security.AllPermission;
            };
            
            grant codeBase "file:${jboss.server.home.dir}/deploy/-" {
             permission java.security.AllPermission;
            };
            
            grant {
             permission java.util.PropertyPermission "*", "read";
             permission java.net.SocketPermission "*", "connect";
             permission javax.management.MBeanServerPermission "findMBeanServer";
            };
            


            The server executes the most (and at the end it starts). However, I get the following exception:


            java.lang.SecurityException: Invalid authentication attempt, principal=null
            at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:647)
            at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:476)
            at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:814)
            at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102)
            at org.jboss.mq.pm.jdbc2.PersistenceManager.getConnection(PersistenceManager.java:1266)
            at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:216)
            at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1356)
            at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192)
            at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:324)
            at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
            at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
            at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
            at $Proxy14.start(Unknown Source)
            at org.jboss.system.ServiceController.start(ServiceController.java:394)
            at org.jboss.system.ServiceController.start(ServiceController.java:411)
            ..
            ..


            How could I bypass this problem? It seems that somehow I should grant a permission for principal = null.



            • 3. Re: Running JBoss with the default sandbox
              Marat Bedretdinov Newbie

              There is a third party solution available that allows you to run your J2EE client in the default "sandbox" secuirty model. In other words you don't need to change client's java policy at all.

              Have a look at http://www.jproxy.com

              Cheers,
              Marat

              • 4. Re: Running JBoss with the default sandbox
                Scott Stark Master

                The only issue with relying on ${user.home}/.java.policy is that this may not be configured to load in a given JDK/JRE installation so there is no guaretee it will be used.

                The other problem with your policy file is that you are using the jboss.home.dir and jboss.server.home.dir system property references but you don't say if you are setting this in the jboss server start script. Policy files are read before jboss sets these properties so in order to use them they must be set on the server vm command line.