Add security management to beanshell

[GoogleCodeExporter]

This is an enhancement which should probably go into a future branch/fork.

A current problem with BeanShell is that it is highly unsecure if run 
within a larger environment.  For example, adding scripting to a J2EE 
environment where the scripts can be user written.   Since BeanShell can 
execute any java code then it can do things that affect the entire 
environment.  A simple example would be System.exit(1) which could bring 
an entire tomcat server down.

A proposed solution to this is implementing your own SecurityManager, but 
this is a very tricky thing to do correctly.  Furthermore, it is desirable 
to allow pure java code to not be managed, but beanshell code to be 
managed.  For example, if I write a custom command I want it to be able to 
do anything, but I dont want user entered scripts to be able to access 
classes or methods outside my "sandbox" (whatever that is).

I propose an enhancement similar to the import() methods which do the 
following, and affect beanshell code only.   Clearly this needs to be 
thought through much more.

1) Add a set of methods which let you setup a list of allowed packages 
and/or allowed classes.   BeanShell script would be unable to instantiate 
any classes not in this list.   However if an instance of these classes 
were set into the beanshell environement from outside (by set() or 
function arguments, or return valids from methods from allowed objects) 
they could be used.   Public static methods not in the list of 
packages/classes could not be called.  Public static variables could not 
be accessed.

The philosophy of this change is "If not allowed you cant do it".
That is security by lists of "allow" not "deny".  That way if new classes 
are added you dont have to keep adding to a list of "bad" classes.

2) Further refinement of #1, allow individual static methods of selected 
classes to be executed. This would be an "allow" list which augments #1.
For example you may want to allow "System.out" to be accessed but not the 
rest of System.

3) Similar to #2, a way to limit global beanshell functions which can be 
called.  Some global beanshell functions could be considered "unsafe" in 
some contexts such as the file access functions.

Original issue reported on code.google.com by dlee.cal...@gmail.com on 9 May 2007 at 12:53

[GoogleCodeExporter]

Changed from Accepted to New

Original comment by dlee.cal...@gmail.com on 9 May 2007 at 12:54

• Changed state: New

[GoogleCodeExporter]

Hello,
 Maybe there should be a priv (priveledged) context to allow some code to run. It would run slower while there 
is a background check. This would work like Try block. But it would return a 
runtime error instead of just an 
exception if run outside the context. Inside, you can get an exception to allow 
you to try other options.

priv//eledged
{
 try
 {
  fs.write("OK");
 }
 catch(PriveledgedAccessException)
 {
  System.out.println("OK");
 }
}

This way you won't have a huge priv block if you want performance. Good day.

Yemi Bedu

Original comment by yemi.b...@gmail.com on 17 Apr 2008 at 11:08

[GoogleCodeExporter]

Hello,
I am looking for such a functionality for 2 days now.
Without it, BeanShell is completly useless for scripting language allowed for
business users. I want to allow users run some scripts based on API, tested for
security and safe. 
Is there a way to implement your own SecurityManager to manage only evaluated 
scripts?
Or maybe there is another way to provide mentioned "allow" list?

Original comment by kami...@gmail.com on 8 Jan 2010 at 11:19

[GoogleCodeExporter]

Can't you use Java's existing SecurityManager facility and just treat the bsh 
evaluation as 
an untrusted operation (i.e. call System.setSecurityManager(...) before bsh 
eval)?

Original comment by s...@google.com on 25 Feb 2010 at 3:48

[GoogleCodeExporter]

This feature would power up BeanShell as an embedded script engine. It's like 
what ClassShutter.visibleToScripts() does for Mozilla Rhino Scriptengine 
(JavaScript).
http://www.docjar.com/docs/api/org/mozilla/javascript/ClassShutter.html

It implements a blacklist as proposed by the reporter.

I appreciate to see such thing in BeanShell.

Original comment by sulai...@googlemail.com on 4 Nov 2010 at 7:33

[GoogleCodeExporter]

I agree with comment 4.

Implementing this feature could easily affect performance.

The mentioned 
http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/ClassShutter.html 
only limits access to specific classes.
But here a method level access filter is requested 
("java.lang.System.println()" is ok but "java.lang.System.exit(int)" is not).

Original comment by pejob...@gmail.com on 21 Feb 2011 at 12:13

[GoogleCodeExporter]

Actually the blacklisting need only happen during the parsing phase. Once 
completed everything that should be block is so the script can be executed.

Original comment by miroslav...@gmail.com on 30 Jun 2011 at 9:53

[GoogleCodeExporter]

Re comment #4: are there any good examples of this anywhere? I'd like to eval 
untrusted scripts submitted via web form in a sandbox context (running in 
something like Tomcat).

Original comment by jdesbon...@gmail.com on 2 Oct 2011 at 12:09

[GoogleCodeExporter]

Hi

any progress on this?

TIA

Leo

Original comment by shik...@gmail.com on 3 Dec 2013 at 5:18

[GoogleCodeExporter]

I don't think this is in the state of "should be done".

As already said, I would advice to use the given security features of java.

Original comment by pejob...@gmail.com on 5 Dec 2013 at 7:48