[jboss-as7-dev] [JNDI] Secure the access to (local) JNDI tree through java permissions?

[Jason Greene]

SRT didn't think this was needed because we no longer allow remote writes to JNDI.

Sent from my iPhone

On Nov 2, 2012, at 8:57 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> The org.jboss.as.naming.JndiPermission was introduced in AS5 mainly to 
> monitor the CRUD operations on the JNDI when running under the Java 
> Security Manager.  This was done as part of Common Criteria Evaluation. 
> We need to bring this back for JNDI operations in AS7.
> 
> On 11/02/2012 04:40 AM, Lukas Krejci wrote:
>> Hi Darran,
>> 
>> seeing you as the assignee of https://issues.jboss.org/browse/AS7-3407, would
>> you be able to comment on the problem I outlined below?
>> 
>> Your help is very much appreciated.
>> 
>> Thanks,
>> 
>> Lukas
>> 
>> On Friday, November 02, 2012 13:16:15 Jaikiran Pai wrote:
>>> I don't think relying on EJB container or other containers to do the
>>> necessary checks is always going to work. You never know what gets bound
>>> to the JNDI and if it doesn't use the JndiPermission check, then that
>>> JNDI bound entry can get exposed to the client.
>>> 
>>> There appears to be a JIRA for this, although I don't know what's being
>>> planned in there https://issues.jboss.org/browse/AS7-3407
>>> 
>>> -Jaikiran
>>> 
>>> On Thursday 01 November 2012 10:07 PM, Lukas Krejci wrote:
>>>> Hi,
>>>> 
>>>> we're in the middle of porting RHQ/JBoss ON from JBoss AS 4.2.3 to JBoss
>>>> AS
>>>> 7.1.1.
>>>> 
>>>> Among many other things we offer the ability to run user scripts (using a
>>>> javax.script.ScriptEngine) inside the server. The scripts can access our
>>>> APIs to perform various functions. But since they're essentially 3rd
>>>> party, we want to execute them in a secured fashion. For that we run RHQ
>>>> with a security manager (allowing all permissions by default) and when
>>>> executing a script we do that in a separate access control context that
>>>> limits what the code being executed can do (like it cannot shutdown the
>>>> server using System.exit(), etc).
>>>> 
>>>> Among other things, we don't want the scripts to access our local EJBs
>>>> because that would mean they would be able to access unsupported and
>>>> possibly insecure APIs.
>>>> 
>>>> When RHQ ran on AS4, we solved the above problem by having our own
>>>> IntialContextFactoryBuilder that essentially wrapped any
>>>> javax.naming.Context in a wrapper that would check for a certain java
>>>> Permission on lookup. All the "normal" code would have it, but the access
>>>> control context the scripts run in would NOT have it. This would stop any
>>>> attempt to do a (local) JNDI lookup with a SecurityException unless the
>>>> JNDI lookup was performed using our "gateway" (that "published" only
>>>> secure remote APIs and called them in a privileged action).
>>>> 
>>>> Now with AS7 I don't think the above is possible anymore. There is a
>>>> org.jboss.as.naming.JndiPermission that would be ideal for our purposes
>>>> but it is not being enforced when doing JNDI lookups of EJBs (as far as I
>>>> could debug this is due to using ServiceBasedNamingStore for looking up
>>>> EJBs, which doesn't do the check for the JndiPermission).
>>>> 
>>>> How would you go about implementing something like above? Would it even be
>>>> a viable approach to take in AS7?
>>>> 
>>>> (One of the obvious solutions would be to implement the security check as
>>>> an interceptor on the EJB calls but we tried to avoid that because that
>>>> would be done on EVERY ejb call all the time, while the security check
>>>> during the JNDI lookup phase would be done only once).
>>>> 
>>>> Thanks,
>>>> 
>>>> Lukas
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev