[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-934) Put code subject to a security manager in privileged blocks

[Ron Sigal (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-934?page=comments#action_12410152 ] 
            
Ron Sigal commented on JBREM-934:
---------------------------------

1. All security sensitive calls have been wrapped in AccessController.doPrivileged() calls.  Most of them are made through methods in org.jboss.remoting.util.SecurityUtility.  All of the methods in SecurityUtility have the same structure.  E.g.,

   static public boolean fileExists(final File file)
   {
      if (skipAccessControl)
      {
         return file.exists();
      }

      return ((Boolean)AccessController.doPrivileged( new PrivilegedAction()
      {
         public Object run()
         {
            return new Boolean(file.exists());
         }
      })).booleanValue();
   }

The value of variable skipAccessControl is defined as follows:

   static
   {
      try
      {
         skipAccessControl = ((Boolean)AccessController.doPrivileged( new PrivilegedExceptionAction()
         {
            public Object run() throws Exception
            {
               boolean b1 = System.getSecurityManager() == null;
               boolean b2 = Boolean.getBoolean(Remoting.SKIP_ACCESS_CONTROL);
               return new Boolean(b1 || b2);
            }
         })).booleanValue();
      }
      catch (PrivilegedActionException e)
      {
         e.getCause().printStackTrace();
      }
   }

That is, if there is no security manager, or if the system property Remoting.SKIP_ACCESS_CONTROL (actual value "skipAccessControl") is set to "true", the AccessController.doPrivileged() calls will be bypassed.  

2. A sample security policy file has been created:  .../src/etc/remoting.security.policy.core.  This file is intended to enumerate all of the privileges needed to run all Remoting features, transports, etc.  The file may be contracted if some features, etc., are not needed.  Some privileges may need to be expanded, depending on the configured location of certain files.  See remoting.security.policy.core for details.

Testing:

Testing these changes falls under JIRA issue JBREM-920 "Create build.xml target to run test suite with a Security Manager", which is still open.  However, currently the jdk 1.4 and jdk 1.5 test suites run with a security manager, and jdk 1.6 runs without a security manager.  Additional privileges needed by the test classes are found in .../src/etc/remoting.security.policy.tests.  This file is concatenated with remoting.security.policy.core to create the policy file used by most tests.  A small set of additional tests, consisting of build.xml targets "tests.functional.main.security" and "tests.functional.main.http.security", run with a more constrained set of privileges, given by the concatenation of remoting.security.policy.core and remoting.security.policy.tests.minimal.  This set of tests includes one test per transport, and is designed to show that the privileges granted in remoting.security.policy.tests do not hide any flaws im remoting.security.policy.core.

> Put code subject to a security manager in privileged blocks
> -----------------------------------------------------------
>
>                 Key: JBREM-934
>                 URL: http://jira.jboss.com/jira/browse/JBREM-934
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 2.4.0.CR2
>
>
> To run in a the Application Server, which might be run in a security manager, Remoting code must wrap all code that needs security privileges in AccessController.doPrivileged() calls.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira