Sandboxed BeanShell?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Sandboxed BeanShell?

Eric Gaudet
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 in.
 
I am willing to contribute a patch for each of these features if people are interested.
 
Thanks,
EG
 
Reply | Threaded
Open this post in threaded view
|

Re: Sandboxed BeanShell?

Archie Cobbs
Eric Gaudet wrote:

> 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.

Not sure if this would be applicable to your situation. We have
had great success in combining XSLT and BeanShell. That is, your
"customer input" (or in my case, our operations team input) comes in
the form of an XML file. Then at some point you run that XML through
your XSLT file, which spits out BeanShell (which is guaranteed to be
well-formed) which you then execute at the appropriate time.

A big benefit of this is that you can validate the XML with an XML schema
at creation time (or later too). The various XML tools know how to read
these schemas and thus become intelligent editors for your language.
Of course, then you can make the "customer input" language as restrictive
as you want. I.e., you define your customer input via a "domain specific
language" (hot phrase these days) based on XML.

The downside of course is that your new language looks like XML. In our
case that's OK, we only do this internally. But it may be possible to
have a "prettier" language which is easily parsed and converted into XML
if XML is not acceptable. On the other hand, some types of customers
might actually prefer schema'd XML.

[Aside: for a long time I thought XSLT could only output XML, but
actually it can output anything. We use it to output shell scripts,
RPM spec files, ant files, and PHP scripts!]

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


-------------------------------------------------------
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]
https://lists.sourceforge.net/lists/listinfo/beanshell-users
Reply | Threaded
Open this post in threaded view
|

Re: Sandboxed BeanShell?

Alexey Zinger
In reply to this post by Eric Gaudet
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
> in.
>  
> I am willing to contribute a patch for each of these features if people
> are interested.
>  
> Thanks,
> EG
>  
>


Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://bsheet.sourceforge.net

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


-------------------------------------------------------
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]
https://lists.sourceforge.net/lists/listinfo/beanshell-users
Reply | Threaded
Open this post in threaded view
|

RE: Sandboxed BeanShell?

Daniel Leuck
In reply to this post by Eric Gaudet

Hello Eric, Mark, and Alexey,

 

> I am willing to contribute a patch for each of these features if people are interested.

 

I think its safe to say people are interested.  If you have implemented this with tests we would love to see it.  The same goes for Mark’s custom security policy.

 

Cheers,

Dan

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Eric Gaudet
Sent: Monday, August 01, 2005 8:58 AM
To: [hidden email]
Subject: [Beanshell-users] Sandboxed BeanShell?

 

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 in.

 

I am willing to contribute a patch for each of these features if people are interested.

 

Thanks,

EG

 

Reply | Threaded
Open this post in threaded view
|

Re: Sandboxed BeanShell?

Paul Franz
I just had a thought. Do you think BCEL could be used insert the
appropriate code to allow the killing of infinite loops?

Paul Franz

Daniel Leuck wrote:

> Hello Eric, Mark, and Alexey,
>
>  
>
>>  I am willing to contribute a patch for each of these features if
> people are interested.
>
>  
>
> I think its safe to say people are interested.  If you have implemented
> this with tests we would love to see it.  The same goes for Mark’s
> custom security policy.
>
>  
>
> Cheers,
>
> Dan
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* [hidden email]
> [mailto:[hidden email]] *On Behalf Of *Eric
> Gaudet
> *Sent:* Monday, August 01, 2005 8:58 AM
> *To:* [hidden email]
> *Subject:* [Beanshell-users] Sandboxed BeanShell?
>
>  
>
> 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 in.
>
>  
>
> I am willing to contribute a patch for each of these features if people
> are interested.
>
>  
>
> Thanks,
>
> EG
>
>  
>



-------------------------------------------------------
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]
https://lists.sourceforge.net/lists/listinfo/beanshell-users
Reply | Threaded
Open this post in threaded view
|

RE: Sandboxed BeanShell?

Daniel Leuck
Hi Paul,

Thank you for the suggestion.  I don't think BCEL would be necessary.  If a
byte code solution is required we would use the light weight ASM library
already included in BeanShell.

Cheers,
Dan

> -----Original Message-----
> From: Paul Franz [mailto:[hidden email]]
> Sent: Monday, August 15, 2005 1:43 PM
> To: Daniel Leuck
> Cc: 'Eric Gaudet'; [hidden email]
> Subject: Re: [Beanshell-users] Sandboxed BeanShell?
>
> I just had a thought. Do you think BCEL could be used insert the
> appropriate code to allow the killing of infinite loops?
>
> Paul Franz
>
> Daniel Leuck wrote:
> > Hello Eric, Mark, and Alexey,
> >
> >
> >
> >>  I am willing to contribute a patch for each of these features if
> > people are interested.
> >
> >
> >
> > I think its safe to say people are interested.  If you have implemented
> > this with tests we would love to see it.  The same goes for Mark's
> > custom security policy.
> >
> >
> >
> > Cheers,
> >
> > Dan
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > *From:* [hidden email]
> > [mailto:[hidden email]] *On Behalf Of *Eric
> > Gaudet
> > *Sent:* Monday, August 01, 2005 8:58 AM
> > *To:* [hidden email]
> > *Subject:* [Beanshell-users] Sandboxed BeanShell?
> >
> >
> >
> > 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
> in.
> >
> >
> >
> > I am willing to contribute a patch for each of these features if people
> > are interested.
> >
> >
> >
> > Thanks,
> >
> > EG
> >
> >
> >




-------------------------------------------------------
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]
https://lists.sourceforge.net/lists/listinfo/beanshell-users