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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
