Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of kwsutter@gmail.com designates
 64.233.162.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=a5SGGgj7zhLwZG+lm6Jvi6tdaARl1DFarOKQqX5AKqmauzoeKrnUEYxjJnHm5nXW0zDIpH77matNrr1mFzpJxLMCqvoYNt8rm0axBZUCTEJqJiYiEBIlLy60tNpFP1aSi3PJnSy+ME68PcjCrDTYRu1wW6t0azfZHh39wnwnAss=
Message-ID: <89c0c52c0705231953g37bcd81blc967cb37cdb2504e@mail.gmail.com>
Date: Wed, 23 May 2007 21:53:12 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: open-jpa-dev@incubator.apache.org
Subject: Re: Enable Java 2 Security in EE environment causes Access denied
 exception
In-Reply-To: <50029D87-BCBB-45D5-9431-A75BD08DD655@SUN.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_119836_8565422.1179975192511"
References: <8e68c8e90705171017g7d6f7088g2d933ccd0b8ed396@mail.gmail.com>
	 <89c0c52c0705221922v4fa847b2lfc5f90bb36a24811@mail.gmail.com>
	 <50029D87-BCBB-45D5-9431-A75BD08DD655@SUN.com>

------=_Part_119836_8565422.1179975192511
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks, Craig.

On 5/23/07, Craig L Russell <Craig.Russell@sun.com> 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.


Done.  OPENJPA-244.

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


I agree, especially for 3rd party JPA providers that are plugged into an app
server's environment.  But, if OpenJPA was "trusted", then this wrapper
approach would suffice.

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


:-)  This seems to be a common theme.  I ran this question by another
participant in the EJB3 expert group and he said basically the same
thing...  I used to be involved with the JCA specification and
implementation and that spec was quite clear on the Java 2 security
expectations.  Too bad there aren't some "boiler plate" sections of these
specs for all JSR's to properly address.

Craig
> >
> > Thanks,
> > Kevin
> >
> > On 5/17/07, Albert Lee <allee8285@gmail.com> 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.getDataCacheManagerI
> >> nstance
> >> (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.createEntityM
> >> anager
> >> (
> >> EntityManagerFactoryImpl.java:190)
> >>     at
> >> com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue
> >> (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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>

------=_Part_119836_8565422.1179975192511--