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

Lukas Krejci lkrejci at redhat.com
Fri Nov 2 05:40:17 EDT 2012


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
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


More information about the jboss-as7-dev mailing list