commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sarel Botha <sa...@botha.us>
Subject Re: [jexl] JEXL Secure Sandbox
Date Wed, 13 Jul 2011 20:34:01 GMT
Hi, Henrib,

I think for the most part it should be kept simple and work out of the 
box with the restrictions from my first e-mail. This should be what most 
people want. Then allow some simple variations as you've described so 
that they can customize this sandboxed version. If they want to do 
something not covered under 'simple' they can override the classes as I 
did. It's pretty easy to do that and the documentation can point them in 
the right direction.

1. I think for classes it should block all by default and use a 
whitelist to let classes through. They can then add to this list to 
expose their own classes. For attributes it should let all through but 
use a blacklist to block things like Object.class and Object.getClass. 
They could then add to this list each class/attribute and class/method 
combination they want to block. If they do want to block by default 
maybe a class can be provided which does that and can be configured in 
the same way.

3. I think this could be very complicated because there are so many 
tricks to get around pattern-matching restrictions like this. For 
example instead of /root you could pass /./root. JEXL is probably not 
the place to try and implement resource security like this. It's not 
possible to do anyway without setting the system property 
'java.security.policy'. With the above in place it shouldn't be possible 
to access these resources. It could become possible to access these 
resources if the user exposes an object that allows this. Again, just 
something in the documentation to point the user in the right direction 
may do.

4. Thanks. I'll change my code to override the Interpreter class instead.

Regards,
Sarel

On 7/6/2011 9:46 PM, henrib wrote:
> Hi Sarel;
>
> This is very interesting; I'm also evaluating options to implement
> "sandboxed" evaluation.
>
> 1. The "white-list" classes could be addressed by (adding code to) filter
> which classes can be instantiated (a pattern matching on the full class name
> or even further, a JEXL expression to use as a condition).
> 1bis: There is also the case of "white-list" properties where you may want
> to hide some properties; an annotation would come to mind but this is
> intrusive.  A less intrusive one would be to describe those as a map of
> class name to allowed method names/signatures list.
>
> The Uberspect could most likely be derived to handle the filtering. It could
> also handle the getClass and forName (2) issue since this is can be see as a
> specialized filter on Object and Class / ClassLoader.
>
> 3. It may be easier to put a file() and/or url() function on the top-level
> context (ie in the JexlContext) that filter the path (pattern matching or
> JEXL expression) and of course, filter out the File and URL classes. By only
> providing what can be accessed through functions, we flank the problem of
> resource access in a generic unintrusive way.
>
> 4. I would tend to rely on the Interpreter class (rather than the
> JexlArithmetic) which is definitely involved in each call; override each
> visit method, check if time did not run-out and delegate to original visit
> if ok. No external watchdog would be needed this way; may be a dedicated
> (runtime) exception could be used to traverse up the stack and end the
> script.
>
> This could be provided as a SandBoxed engine - created from a JexlEngine
> instance through a createSandboxed(Map&lt;String, List&lt;String&gt;>
> whiteList, int timeOut) to filter classes/methods - that would wrap/delegate
> to a filtering Uberspect and time-checking Interpreter.
>
> Comments, loopholes, etc more than welcome. :-)
> Cheers
> Henrib
>
>
> --
> View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-JEXL-Secure-Sandbox-tp3626959p3650468.html
> Sent from the Commons - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message