Hello, is there a way of controlling the security context for the
We would like to use the interpreter as an embedded scripting engine but
limit its use to a safe or sandboxed security context.
We would like to do this without running multiple JVM's or enabling a
security policy for our current application platform.
Any advice welcome
On Wed, Apr 24, 2002 at 10:52:12AM -0700, Chris Greener wrote:
> Hello, is there a way of controlling the security context for the
> We would like to use the interpreter as an embedded scripting engine but
> limit its use to a safe or sandboxed security context.
> We would like to do this without running multiple JVM's or enabling a
> security policy for our current application platform.
There currently any facility to do this other than the ones your aware of
(Java policy file, etc.).
I'm interested in hearing what would be useful. But I think real security
is only possible in conjunction with a Java security policy.
For example, we could install a simple "execution manager" that could be
queried to allow each object construction or method execution... We could
then write a small framework to allow you to list packages, classes and
methods that are ok, or not ok, etc. But That's really not enough...
A creative person could use BeanShell to load a Java class that could then do
anything... so we'd have to watch class loading as well and I'm sure there
are other holes. I have little confidence in our ability to guarantee real
security unless there is some way to use the java policy framework.
It should be possible to associate a java.security.Principal with the BeanShell
engine, such that only the BeanShell code is guarded by a particular security
policy. But I am not up on the security API enough to know how to do this.