AccessControlExceptions when running with SecurityManager

glassfishrobot commented 7 years ago

As reported by @wxwesther via email:

In order to test IdentityStorePermission related requirements, I enabled SecurityManager in Glassfish. And IdentityStorePermission works as expected.

But unfortunately, there are several HAM and SecurityContext test cases failed (while all of them are PASSED before enabling SecurityManager).

Here I have 2 questions:

Is it correct or required to run all TCK with SecurityManager enabled?
If yes, what is the expected result? Access denied exception is thrown or works same as SecurityManager disabled after adding add permissions.xml in those test cases? If the latter, what is the class-name and method name in permission should I add in permissions.xml?

If no, I will try to find a way to enable/disable SecurityManager only for IdentityStorePermission related test cases.


[2017-08-15T20:11:00.369-0700] [glassfish 5.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=130 _ThreadName=AutoDeployer] [timeMillis: 1502853060369] [levelValue: 1000] [[

Exception while invoking class com.sun.enterprise.web.WebApplication start method

java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getProperty.authconfigprovider.factory")

    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:136)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:536)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:535)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:566)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:558)
    at java.security.AccessController.doPrivileged(Native Method)

[2017-08-15T19:24:43.668-0700] [glassfish 5.0] [FINE] [] [javax.enterprise.system.core.security] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1502850283668] [levelValue: 500] [CLASSNAME: com.sun.enterprise.security.provider.BasePolicyWrapper] [METHODNAME: doImplies] [[

JACC Policy Provider, failed Permission Check at :

java.lang.Exception

    at com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:408)
    at com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:244)
    at java.security.ProtectionDomain.implies(ProtectionDomain.java:285)
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:450)
    at java.security.AccessController.checkPermission(AccessController.java:884)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:313)
    at org.glassfish.soteria.authorization.JACC.getFromContext(JACC.java:156)
    at org.glassfish.soteria.authorization.JACC.getSubject(JACC.java:67)
    at org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.getCallerPrincipal(ReflectionAndJaccCallerDetailsResolver.java:56)

[2017-08-15T19:24:43.673-0700] [glassfish 5.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1502850283673] [levelValue: 900] [[

StandardWrapperValve[com.sun.ts.tests.securityapi.securitycontext.callerdata.Servlet]: Servlet.service() for servlet com.sun.ts.tests.securityapi.securitycontext.callerdata.Servlet threw exception

java.security.AccessControlException: access denied ("java.security.SecurityPermission" "setPolicy")

    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
    at java.security.AccessController.checkPermission(AccessController.java:884)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:313)
    at org.glassfish.soteria.authorization.JACC.getFromContext(JACC.java:156)
    at org.glassfish.soteria.authorization.JACC.getSubject(JACC.java:67)
    at org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.getCallerPrincipal(ReflectionAndJaccCallerDetailsResolver.java:56)
    at org.glassfish.soteria.SecurityContextImpl.getCallerPrincipal(SecurityContextImpl.java:78)
    at com.sun.ts.tests.securityapi.securitycontext.callerdata.Servlet.doGet(Servlet.java:50)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
    at sun.reflect.GeneratedMethodAccessor158.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

glassfishrobot commented 6 years ago

Issue Imported From: https://github.com/javaee/security-soteria/issues/173
Original Issue Raised By:@wmhopkins
Original Issue Assigned To: @wmhopkins

glassfishrobot commented 7 years ago

@arjantijms Commented I don't fully know what the official TCK rules are, but indeed, to run with a Java SE SecurityManager the necessary extra permissions should be granted. I think we briefly discussed this on one of the last calls when the topic was about these permissions; working with the JASPIC factory requires certain permissions. I think they're all java.security.SecurityPermission.SecurityPermission(String) with String being the name of a more specific permission (as defined by public fields of javax.security.auth.message.config.AuthConfigFactory).

Obtaining several JACC contexts also requires a permission, namely java.security.SecurityPermission.SecurityPermission(String) with String being "setPolicy" here. (the name is a wee bit peculiar, as no policy is actually being set, but instead a handler is being obtained).

glassfishrobot commented 7 years ago

@wmhopkins Commented The issue isn't so much a question of permissions as a question of coding Soteria properly -- the Glassfish runtime jars should normally have AllPermission.

I've updated Jaspic.java and JACC.java so that invocations on the AuthConfigFactory and PolicyContext.getContext(), respectively, are done inside PrivilegedAction blocks. As such, the Soteria runtime will need the specified permissions (and should have them via the GF grants), but applications will not require special permissions to call into Soteria.

@wxwesther -- Hopefully the changes I'm about to commit will address these issues -- and maybe even #174, if we're lucky. Let me know if the exceptions go away, or if others appear.

glassfishrobot commented 7 years ago

@wmhopkins Commented Re-opening to allow for further investigation -- there are several places where Soteria calls System.getProperty(), which will throw a SecurityException if permission not granted. These may need to execute in a privileged block, or may not, if the code can't be reached from an application context.

Either way, since we're not getting exceptions for those under test, I'm deferring for now. They can be fixed in the next release.

eclipse-ee4j / soteria

AccessControlExceptions when running with SecurityManager #173