10 Replies Latest reply on Mar 9, 2010 11:32 PM by flavia.rainone

Security problems with org.jboss.test:jboss-test 1.1.5.GA

flavia.rainone Mar 5, 2010 8:42 AM

I'm not sure if this belongs to this forum, but I couldn't find a more appropriate forum for this either.

In JBoss AOP, we are currently using jboss:jboss-test: 1.0.3.GA. We can't upgrate because whenever we try to upgrade we start seeing several Security Errors at all points of our testsuite that try to access the System Properties.

An example of this:

java.lang.reflect.InvocationTargetException
        at org.jboss.test.AbstractTestDelegate.getDelegate(AbstractTestDelegate.java:73)
        at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:62)
        at org.jboss.test.AbstractTestCaseWithSetup.setUp(AbstractTestCaseWithSetup.java:103)
 Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:1252)
        at java.lang.System.getProperties(System.java:580)
        at org.jboss.test.aop.AOPTestDelegate$1.run(AOPTestDelegate.java:51)
        at org.jboss.test.aop.AOPTestDelegate$1.run(AOPTestDelegate.java:48)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.jboss.test.aop.AOPTestDelegate.<init>(AOPTestDelegate.java:47)
        at org.jboss.test.aop.AOPTestWithSetup.getDelegate(AOPTestWithSetup.java:53)

This is AOPTestDelegate constructor implementation:

   public AOPTestDelegate(Class<?> clazz)
   {
      super(clazz);
      
      systemProps = AccessController.doPrivileged(new PrivilegedAction<Properties>() 
      {
         public Properties run()
         {
line 47>>>            return (Properties)System.getProperties().clone();
         }
      });
   }

Another example:

access denied (java.util.PropertyPermission org.jboss.test.logging.LogginPlugin read)
java.security.AccessControlException: access denied (java.util.PropertyPermission org.jboss.test.logging.LogginPlugin read)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
        at java.lang.System.getProperty(System.java:686)
        at org.jboss.test.logging.LoggingPlugin.getInstance(LoggingPlugin.java:47)
        at org.jboss.test.AbstractTestDelegate.setUpLogging(AbstractTestDelegate.java:158)
        at org.jboss.test.AbstractTestDelegate.setUp(AbstractTestDelegate.java:125)
        at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
        at org.jboss.test.AbstractTestCaseWithSetup.setUp(AbstractTestCaseWithSetup.java:103)
        at org.jboss.test.aop.annotatedAdviceParams.Arg2TestCase.setUp(Arg2TestCase.java:62)

This last example is even more serious, because it happens on AbstractTestCaseWithSetup.setUp execution.

I couldn't find any refrences for how to solve this apart from a hack Adrian mentioned in another thread.

Does anybody know why these tests have no permission to access the System Properties? How do we work around this issue?

1. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

anil.saldhana Mar 5, 2010 8:53 AM (in response to flavia.rainone)

Look at the last comment in Adrian's thread. He says the test is designed such that missing privileged blocks in the code that is being tested can be determined and applied. This is really really important for projects to do before hand.

In the end, it is I who gets to do the clean up of figuring out the privileged blocks in projects and notify the projects integrating into the AS/EAP.

I think we should try to figure out the privileged block in the code that is being tested (and I am presuming AOP).
Actions
2. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

alesj Mar 5, 2010 8:57 AM (in response to anil.saldhana)

I think we should try to figure out the privileged block in the code that is being tested (and I am presuming AOP).
No, as you can see, in this case it's the test class that needs to read off System properties.
I would simply suspend the SM for this Sys props invocation, only to restore it to potentially indentify any AOP missing blocks Anil is talking about.
Actions
3. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

anil.saldhana Mar 5, 2010 9:32 AM (in response to alesj)

Why not add a Privileged Block to the test class rather than do all the SM disable/enable circus?

In addition to the Priv Block addition, you will have to figure out what is the security policy the security mgr is using. Because you will have to add policy permission there for your test class.
Actions
4. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

alesj Mar 5, 2010 9:55 AM (in response to anil.saldhana)

Why not add a Privileged Block to the test class rather than do all the SM disable/enable circus?
This won't work -- as the test itself is already under security, hence privileged block would kick-in too late.
e.g. otherwise one could always get past it by simply declaring pb -- but who knows this better then you ;-)

In addition to the Priv Block addition, you will have to figure out what is the security policy the security mgr is using. Because you will have to add policy permission there for your test class.
OK, unless you do this -- which is much more work than simple SM disable/enable.

It's not like we're breaching security here :-), it's just that we want to stick with it,
in order to see if the tested code actually has proper PBs, not the test itself. ;-)
Actions
5. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

anil.saldhana Mar 5, 2010 10:04 AM (in response to alesj)

If the SM disable for the test class is simpler, go for it.

Surprisingly, Adrian has not documented his test class. He usually is very good at it. Ha Ha!!

Adding a Privileged Block does not mean you are bypassing security (in all cases).
Actions
6. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

adrian.brock Mar 5, 2010 10:13 AM (in response to alesj)

Looks like a bug to me, but I don't see any recent changes in the code that would cause the problem?

The SecurityManager shouldn't be installed until it runs AbstractTestDelegate.setUp()
The error above is happening in the constructor of the delegate.

Its only after that happens that you can do:

delegate.enableSecurity = true;

Most likely, there is a security manager still around from a previous test?
1 of 1 people found this helpful
Actions

7. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

flavia.rainone Mar 8, 2010 1:42 PM (in response to adrian.brock)

adrian@jboss.org wrote:

Looks like a bug to me, but I don't see any recent changes in the code that would cause the problem?

The SecurityManager shouldn't be installed until it runs AbstractTestDelegate.setUp()
The error above is happening in the constructor of the delegate.

Its only after that happens that you can do:

delegate.enableSecurity = true;

Most likely, there is a security manager still around from a previous test?

You're right!

Taking a better look, I found this:

public class AOPTestDelegate extends AbstractTestDelegate
{
    public void tearDown() throws Exception
    {
>>>       //TODO Figure out cause of security exception when making this call
>>> //       super.tearDown();
       String deployedByClassLoader = (String)systemProps.get(EclipseTestTransformer.CLASSLOADER_DEPLOYED_XML); 
       if (deployedByClassLoader != null)
       {
          URL url = Thread.currentThread().getContextClassLoader().getResource(deployedByClassLoader);
          AspectXmlLoader.undeployXML(url);
       }
    }
    
}

AbstractTestDelegate.setUpSecurity defines a SecurityManager, and AbstractTestDelegate.tearDownSecurity should set the SecurityManager as null. This is not happening, because AbstractTestDelegate.tearDown is overwritten and the call to super.tearDown is commented out.

Uncomenting this call took me to:

Testcase: testBasic took 1.531 sec
        Caused an ERROR
access denied (java.lang.RuntimePermission setSecurityManager)
java.security.AccessControlException: access denied (java.lang.RuntimePermission setSecurityManager)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.System.setSecurityManager0(System.java:272)
        at java.lang.System.setSecurityManager(System.java:263)
        at org.jboss.test.AbstractTestDelegate.tearDownSecurity(AbstractTestDelegate.java:195)
        at org.jboss.test.AbstractTestDelegate.tearDown(AbstractTestDelegate.java:142)
        at org.jboss.test.aop.AOPTestDelegate.tearDown(AOPTestDelegate.java:66)
        at org.jboss.test.AbstractTestSetup.tearDown(AbstractTestSetup.java:73)
        at org.jboss.test.AbstractTestCaseWithSetup.tearDown(AbstractTestCaseWithSetup.java:112)

From that, I'm assuming that I should define a security policy that allow AbstractTestDelegate to call setSecurityManager. Is that correct?

8. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

adrian.brock Mar 9, 2010 5:36 AM (in response to flavia.rainone)

The setting of the SecurityManager to null in tearDownSecurity() needs to be in a privileged block.
Its failing because your AOPTestDelegate doesn't have the permission.
Actions
9. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

alesj Mar 9, 2010 6:05 AM (in response to adrian.brock)

The setting of the SecurityManager to null in tearDownSecurity() needs to be in a privileged block.
Its failing because your AOPTestDelegate doesn't have the permission.
https://jira.jboss.org/jira/browse/JBTEST-15
1 of 1 people found this helpful
Actions
10. Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA

flavia.rainone Mar 9, 2010 11:32 PM (in response to alesj)

alesj wrote:

The setting of the SecurityManager to null in tearDownSecurity() needs to be in a privileged block.
Its failing because your AOPTestDelegate doesn't have the permission.
https://jira.jboss.org/jira/browse/JBTEST-15
Tx! I ran jboss aop tests against jboss-test trunk and got no failures :-)
I'll commit this as soon as a new version of jboss-test.jar is available:
https://jira.jboss.org/jira/browse/JBAOP-773
Actions

Go to original post