Re: [jexl] JEXL Secure Sandbox

[henrib <he...@apache.org>]

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<String, List<String>>
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

Re: [jexl] JEXL Secure Sandbox

[henrib <he...@apache.org>]

Hi again,
On the time constraint issue and playing with it, I now understand why you
went the proper Callable/Future route (not some lousy external timing
solution...).
A few functions in the interpreter only need to check the
interrupted/cancelled status (calling methods and ctors, accessing/setting
properties, looping constructs and resolving identifiers); with those, we
are guaranteed to check the interruption soon enough.
I'll commit code in the trunk soon to make handling script
cancellation/interruption a core feature and add Callable creation from
script.
Cheers
Henri

--
View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-JEXL-Secure-Sandbox-tp3626959p3665785.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

Re: [jexl] JEXL Secure Sandbox

[henrib <he...@apache.org>]

Hi Sarel,
On point 4/, I've created JEXL-115 and just committed some code/tests in the
trunk. I hope this will allow you to avoid having to derive JexlArithmetic
or Interpreter.

On point 3/, I agree that full access to the system can only be controlled
by a security policy. In "closed" environments where what is accessible is
specific to the application itself, it is easy to control access through
functions/methods (probably the only way too).

On point 1/, a "white" list of classes - with an optional set of
methods/properties and a flag to consider whether these are "white" or
"black" would do the trick. In all cases, Object.class and Object.getClass
would be "black" by default; the constructor(s) would be referred to as as
the Simple class name in white/black lists.
I'd probably add an option to consider that classes not in the white list do
not have any restrictions (String, Integer, etc would be painful to
declare).
Does this seem a good compromise ?

Cheers
Henrib

--
View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-JEXL-Secure-Sandbox-tp3626959p3666165.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

Re: [jexl] JEXL Secure Sandbox

[Sarel Botha <sa...@botha.us>]

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<String, List<String>>
> 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