[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-920) Create build.xml target to run test suite with a Security Manager

[David Lloyd (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-920?page=comments#action_12403948 ] 
            
David Lloyd commented on JBREM-920:
-----------------------------------

Many tests are passing despite access failures.  I've added a "tripwire" sort of security manager that logs the violations, with interesting results.  For example:

java.security.AccessControlException: access denied (java.util.PropertyPermission org.jboss.logging.Logger.pluginClass read)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
        at java.security.AccessController.checkPermission(AccessController.java:427)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at org.jboss.test.security.LoggingSecurityManager.checkPermission(LoggingSecurityManager.java:22)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
        at org.jboss.test.security.LoggingSecurityManager.checkPropertyAccess(LoggingSecurityManager.java:191)
        at java.lang.System.getProperty(System.java:662)
        at org.jboss.logging.Logger.init(Logger.java:359)

Do we need an updated jboss logging? Ours is: Implementation-Version: 4.0.4beta (build: CVSTag=Branch_4_0 date=200601031254)  How do we decide which version to use?  I presume that we're getting the above problem because the Logger isn't doing System.getProperty within a privileged block.


> Create build.xml target to run test suite with a Security Manager
> -----------------------------------------------------------------
>
>                 Key: JBREM-920
>                 URL: http://jira.jboss.com/jira/browse/JBREM-920
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ron Sigal
>         Assigned To: David Lloyd
>             Fix For: 2.4.0.GA
>
>
> From Anil Saldana:
> Presuming that you have a test suite and either use ANT or Maven, I
> recommend an extra target to run the test suite in a Java Security
> Manager with minimal permissions.  So for ANT, you will have an
> additional target. For MAVEN, you can use a profile.
> The idea is that you have a Java Security Policy file in which you
> provide unlimited permission to third party libraries and minimal
> permissions to your own code. This exercise is to detect critical
> sections of code that need special privileges and get into privileged
> blocks.   If you have an extra target for the security manager and your
> test runs happen on hudson, you can detect issues with security manager
> as new code gets added.
> Please do not have one test that does System.setSecurityManager  but run
> your entire test suite via the security manager
> (-Djava.security.manager  -Djava.security.policy=somefile).
> Example:  (Take a look by clicking "Configure" on the LHS)
> http://hudson.qa.jboss.com/hudson/job/JBossSX_SecurityManager/
> http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/trunk/pom.xml
> Now if your head is spinning or you do not care about security or do not
> have the time to do it, please tell me.  I can engage myself, someone
> from JBoss Security Team or the QA person handling your project to add a
> JIRA issue (and make the build.xml/pom.xml changes for your project).
> Why is this important?
> * Because many customers run JBAS in a security manager and we need to
> detect issues in our own code.  Also during a recent integration work
> with JBoss Messaging for the SOA platform, there was one issue with
> remoting (JBREM-811) that gave some head ache to Clebert and Ron (who is
> still reeling). It took some cycles from me also.
> * We need to have tests running in a security manager on an ongoing basis.
> I understand that there are resource issues in various projects. But
> that does not discount the work that we need to do before we ship JBAS. ;) 

-- 
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