[Fwd: Re: Sandboxed BeanShell?]

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Fwd: Re: Sandboxed BeanShell?]


I'd also like to see this.  I've fixed security as best I can with a
custom security policy, but it woudl be great to have this integrated
into BeanShell.

Mark McKay

Alexey Zinger wrote:

>Hear, hear.  I was just recently contemplating a good way to make a
>BeanShell-based app of mine secure.  At its core is the ability to let the user
>define their own scripted functionality as well as run someone else's and I
>wanna find a clean and flexible way to control the security and permissions.
>This is not an easy problem of course.  I think the cleanest way would be
>through using and extending policy files.  I'm not an expert on this, but so
>far it looks like we can do quite a bit using file and reflect permissions with
>Java's out-of-the-box features.  Inifinite loops and such are a whole other
>story of course.
>--- Eric Gaudet <[hidden email]> wrote:
>>Hi all,
>>I'm new to BeanShell and I'm evaluating the possibility to include it in
>>our product.
>>So far, I'm very impressed with the features. It's a very powerfull tool
>>for developers. However, I fear it could be a very insecure scripting
>>tool in hands of customers.
>>Let me explain: I'm looking for a macro evaluator with a well-defined,
>>limited number of features, to be embedded in our application.
>>"Customers" actually refers to administrators in customer sites
>>preparing scripts for user actions. Scripts cannot be uploaded by just
>>anybody. But people make mistakes, even developers, and killing a
>>production server because of a bug in a script is not an option. Also,
>>part of our API is not public and should only be used internally.
>>Some of my concerns are similar to the one expressed in the "too
>>powerfull" thread. I'm very unhappy with the answers I read: not
>>allowing scripts with infinite loops is a *very* legitimate request, and
>>the answers were either silly or sounded like people didn't care.
>>Most embedded scripting engines address the problem by limiting the
>>number of "steps" allowed within one run. The definition of "steps"
>>doesn't have to be strict and can assume that external java classes
>>don't create infinite loops themselves. It's just a matter of counting
>>the number of AST objects evaluated and throw an exception if the
>>maximum defined in the interpreter is reached.
>>Another concern is the unrestricted access to classes by scripts. I'm
>>talking about the ability to import any class at any time. I know that
>>there are security settings, but what I really want is to lock the
>>classpath accessible from inside a script. Basically, disabling the
>>import command would give more control over what's runnable by a script:
>>my macro evaluator would never be allowed to create a swing window and
>>wait forever for a button to be pressed on a remote server I rarely log
>>I am willing to contribute a patch for each of these features if people
>>are interested.
>2001 Honda CBR600F4i (CCS)
>1992 Kawasaki EX500
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>Beanshell-users mailing list
>[hidden email]