Re: Enable Java 2 Security in EE environment causes Access denied exception

[Marc Prud'hommeaux]

I asked a number of times for a security audit to be made of the  
security implications of JPA and it was never taken up. Most of the  
vendors make extensive use of privileged operations including  
getting system properties, reflection, and class loader operations  
and IMHO not enough attention was paid to getting it right.

That includes us. To be perfectly frank, in all the years of Kodo and  
OpenJPA, it has simply never been an issue.

Which doesn't mean that we shouldn't endeavor to fix the problems and  
do it all the right way, security-wise. I'm just pointing out that  
the demand for well-behaved security-sensitive applications is not as  
high as one might expect.



On May 23, 2007, at 9:43 AM, Craig L Russell wrote:

On May 22, 2007, at 7:22 PM, Kevin Sutter wrote:

Here's my take (just to generate some discussion)...

Right now, it doesn't seem like OpenJPA is ready for Java 2 Security.

It's a bug that OpenJPA doesn't use doPrivileged blocks around  
security-protected APIs.

Can you file a JIRA issue with as many of these cases as you can  
find? They need to be fixed.

As
Albert has pointed out, there only seems to be two places in the  
code where
doPriv blocks exist.  It would seem that any application-managed  
path that
would attempt to access secure operations would require a doPriv  
block.

Right.

This may also apply to the container-managed paths, but more than  
likely,
these paths have some type of application-server wrapper around  
the OpenJPA
objects and they could do the proper doPrivs.

Doubtful. It would be a bug for trusted code to wrap a call to  
untrusted code in a doPrivileged block. That would defeat the  
architecture of the security model. Rather, each component that  
needs to access secure resources needs to wrap the call in  
doPrivileged blocks.

It would also seem that we
would need to provide instructions for proper updating of the  
policy files
(for both the application-managed and container-managed scenarios).

Correct.

I know we're hitting these type of problems in the WebSphere  
environment.  I
would be surprised if other app servers won't be experiencing similar
problems if Java 2 security is turned on.  We're just trying to  
figure out
the who's responsible for what processing.

I've been through this exercise with JDO and put doPrivileged  
blocks around everything that needed it. It turned out to be about  
40 places in the code. Not a big deal.

Patrick, were there any discussions on the expert group concerning  
the
relationship between JPA and the Java 2 Security?

I asked a number of times for a security audit to be made of the  
security implications of JPA and it was never taken up. Most of the  
vendors make extensive use of privileged operations including  
getting system properties, reflection, and class loader operations  
and IMHO not enough attention was paid to getting it right.

Craig

Thanks,
Kevin

On 5/17/07, Albert Lee <[EMAIL PROTECTED]> wrote:

I ran into the following exception when I enabled Java 2 security  
in the
Java EE environment using openjpa in the WebSphere environment:

java.security.AccessControlException: Access denied (
java.lang.RuntimePermission getClassLoader)
    at java.security.AccessController.checkPermission(
AccessController.java
:104)
    at java.lang.SecurityManager.checkPermission 
(SecurityManager.java:547)
    at com.ibm.ws.security.core.SecurityManager.checkPermission(
SecurityManager.java:189)
    at java.lang.Thread.getContextClassLoader(Thread.java:490)
    at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
Configurations.java:232)
    at org.apache.openjpa.lib.conf.Configurations.newInstance(
Configurations.java:194)
    at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
ObjectValue.java
:103)
    at org.apache.openjpa.lib.conf.PluginValue.instantiate(
PluginValue.java
:101)
    at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
ObjectValue.java
:79)
    at

org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManager 
Instance
(OpenJPAConfigurationImpl.java:583)
    at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
AbstractBrokerFactory.java:169)
    at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
DelegatingBrokerFactory.java:142)
    at

org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntity 
Manager
(
EntityManagerFactoryImpl.java:190)
    at
com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValu 
e
(StatelessCounterBean.java:63)

The scenario is a openjpa entity manager factory is injected to a
stateless
session bean and it is trying to create an EntityManager from the  
factory.
Since the factory is directly injected in the application, the  
container
has
no involvment in handling the AccessController.doPrivileged().   
Another
similiar scenario is Persistence.createEntityManagerFactory() is  
called
from
within a stateless session bean, in which a similiar but different
security
related symptom is surfaced. These tests run successfully when  
Java 2
security is disabled. A security policy has put in place in the  
app server
to give all permissions to the openjpa jar files in the app server.

For experimentation, I add a doPrivilege block in the
Configurations.findDerivedLoader where the above exception took  
place and
I
was able to by-pass the failure and the doPriv seems to work.  
However I
went
into the same exception in different places when  
getSystemClassLoader()
and
other privileged operations are used.

Questions:
1) How is security being handled in openjpa or JPA in general?
2) What is the philosphy of putting doPrivilege construct around  
security
sensitive code in openjpa? I only find 2 instances of doPrivilege  
usage in
openJPA.
3) Who is responsible to define and enable security in a app server
environment?
4) Is injecting a provider entity manager factory to user code an  
valid
procedure? I understand EntityManager proxy/wrapper is needed for
persistence context injection but I see no reason why provider's  
entity
manager factory can not be injected to user code.

Am I way off base regarding security in OpenJPA and/or JPA in  
general?

Any insights into this topics is greatly appreciated.
Thanks.
Albert Lee.


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!