Invalid Issue: SECURITY-340

[alrubinger]

I've opened https://jira.jboss.org/jira/browse/SECURITY-340, rejected by Anil as invalid.

What steps do I need to take to avoid:

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission org.jboss.security.plugins.
JBossSecurityContext.setSecurityManagement)
 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.security.plugins.JBossSecurityContext.setSecurityManagement(JBossSecurityContext.java:123)
 at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:119)

?

S,
ALR

[starksm64]

Two things are needed:
1. A permission grant for RuntimePermission or an java.security.AllPermission for the ejb3 interceptor codebase. Looking at the testsuite/src/resources/securitymgr/server.policy it is using java.security.AllPermission for the jboss lib dirs so that should be good.
2. A privileged block in the Ejb3AuthenticationInterceptorv2 around the call to the JBossSecurityContext.setSecurityManagement at line 119:

 SecurityActions.setSecurityContext(sc); // line 116, need similar call for setSecurityManagement

 //TODO: Need to get the SecurityManagement instance
 sc.setSecurityManagement(getSecurityManagement());

There is already a privileged block method in the SecurityActions for the call to set the SecurityManagement on the SecurityContext. Something similar is needed for the SecurityManagement:

 static void setSecurityManagement(final SecurityContext sc, final ISecurityManagement sm)
 {
 AccessController.doPrivileged(new PrivilegedAction<Object>(){

 public Object run()
 {
 sc.setSecurityManagement(sm);
 return null;
 }});
 }

or, the following if the SecurityContext should be obtained based on the previous SecurityActions.setSecurityContext(sc) call:

 static void setSecurityManagement(final ISecurityManagement sm)
 {
 AccessController.doPrivileged(new PrivilegedAction<Object>(){

 public Object run()
 {
 SecurityContext sc = getSecurityContext()
 sc.setSecurityManagement(sm);
 return null;
 }});
 }

The TODO about having the SecurityManagement instance injected rather than created anew each time also seems like an issue.

[alrubinger]

2. A privileged block in the Ejb3AuthenticationInterceptorv2 around the call to the JBossSecurityContext.setSecurityManagement at line 119:

Yes, took care of this earlier today: https://jira.jboss.org/jira/browse/EJBTHREE-1619.

The TODO about having the SecurityManagement instance injected rather than created anew each time also seems like an issue.

I believe this is https://jira.jboss.org/jira/browse/JBAS-4722.

S,
ALR

[starksm64]

I don't see where the Ejb3AuthenticationInterceptorv2 is being configured in a AS deployment, so I don't see how that can be addressed as a JBAS issue. I guess its this AuthenticationInterceptorFactory in ejb3-interceptors-aop.xml that is creating the interceptor:

 <interceptor factory="org.jboss.ejb3.security.AuthenticationInterceptorFactory" scope="PER_CLASS"/>

but then that needs to be updated to allow for injection, or more likely the stack of interceptors needs to be created directly as beans. What's the state of the -aop.xml supporting fully configured stack of beans rather than using this older factory based creation?

[anil.saldhana]

That jira issue was created when ejb3 resided in the AS workspace.

[alrubinger]

So how would we like to move forward? And who becomes the maintainer of EJB3 security integration?

S,
ALR

[anil.saldhana]

I don't see where the Ejb3AuthenticationInterceptorv2 is being configured in a AS deployment, so I don't see how that can be addressed as a JBAS issue. I guess its this AuthenticationInterceptorFactory in ejb3-interceptors-aop.xml that is creating the interceptor:

 <interceptor factory="org.jboss.ejb3.security.AuthenticationInterceptorFactory" scope="PER_CLASS"/>

but then that needs to be updated to allow for injection, or more likely the stack of interceptors needs to be created directly as beans. What's the state of the -aop.xml supporting fully configured stack of beans rather than using this older factory based creation?

I do not think the injection mechanism exists yet. The JIRA issue that I created was primarily to get something along those lines started.

We really need to be able to create ejb container in the AS to allow direct injection. Currently the ejb2 deployer based approach to creating containers is also not modern.

[starksm64]

The first issue is just to get the privileged block in place and the test will pass. Its a secondary issue to update the stack configuration.

[alrubinger]

The first issue is just to get the privileged block in place and the test will pass. Its a secondary issue to update the stack configuration.

Yes, this is done and passing when running the test against EJB3 Plugin.

The next EJB3 release will bring this in as a default. This is in addition to the other fixes I'd done yesterday to bring tests-security-manager green. One failure remains as UnAuthorized; Anil will look at it.

S,
ALR