(Sandbox?) Ensuring restricted access to plugins...

[Thomas G. Marshall]

I'm writing an app that will implement a plugin architecture. Furthermore,
it is also going to use a plug-in like facility to manage internal scripts.
This means that the application will freely accept jars of .class's written
by others.

Does the security manager + reflection classes allow a sandbox to contain
such pluggins? Is there something else that allows me to do this other than
programmatically sniffing through the code looking for access to potentially
dangerous classes like, oh, File?

I don't want to have a 3rd party send in a malicious plugin that ends up
erasing someone's disk, or drops in a virus, etc.

 

[Andrew Thompson]

I'm writing an app that will implement a plugin architecture. Furthermore,
it is also going to use a plug-in like facility to manage internal scripts.
This means that the application will freely accept jars of .class's written
by others.

Are there any constraints on the classes?
- must implement a particular interface?
- must be declared in specific package?
- the end user can run a plug-ins 'main()',
after selecting it from a list of 'main()'
classes found in the jar?

Any 'plug-in' architecture might suggest the first..

Does the security manager + reflection classes allow a sandbox to contain
such pluggins?

Sure[1] you can set your own security manager[2], then instanceof
allow your own classes to do whatever they need to do, while
restricting ..everything else to a limited sub-set as required.

[1] I am not a security expert, or perhaps more importantly,
a clever 'anti-security' expert..

[2]
<http://groups.google.com/group/comp.lang.java.programmer/msg/f29ab45389d9f5f2>

 

[Roedy Green]

I don't want to have a 3rd party send in a malicious plugin that ends up
erasing someone's disk, or drops in a virus, etc.

I have never done this, but I suspect if you look at how sun invents
new permission types, you can do the same, then the policy file would
need to grant permission. However all-permissions so popular, would
encompass that.

 

[Lee Fesperman]

I'm writing an app that will implement a plugin architecture. Furthermore,
it is also going to use a plug-in like facility to manage internal scripts.
This means that the application will freely accept jars of .class's written
by others.

Does the security manager + reflection classes allow a sandbox to contain
such pluggins? Is there something else that allows me to do this other than
programmatically sniffing through the code looking for access to potentially
dangerous classes like, oh, File?

I don't want to have a 3rd party send in a malicious plugin that ends up
erasing someone's disk, or drops in a virus, etc.

A Security Manager would the normal solution for such a sandbox. Also, if you can
specify interface(s) that your plugins write to, you don't need reflection (other than
Class.forName().newInstance() ...)

If you need to run under an existing Security Manager, you could use the sandbox
classloader solution I mentioned in a nearby thread -- "Custom Class Loaders".

 

[Chris Uppal]

Does the security manager + reflection classes allow a sandbox to contain
such pluggins? Is there something else that allows me to do this other than
programmatically sniffing through the code looking for access to potentially
dangerous classes like, oh, File?

It would probably be worth spending an hour or two looking into the full
richness of the security model:
http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc.html

-- chris

 

[Ross Bamford]

I'm writing an app that will implement a plugin architecture.
Furthermore,
it is also going to use a plug-in like facility to manage internal
scripts.
This means that the application will freely accept jars of .class's
written
by others.

Does the security manager + reflection classes allow a sandbox to contain
such pluggins? Is there something else that allows me to do this other
than
programmatically sniffing through the code looking for access to
potentially
dangerous classes like, oh, File?

I don't want to have a 3rd party send in a malicious plugin that ends up
erasing someone's disk, or drops in a virus, etc.

A little while ago I wrote a 'modular development' framework that
basically combined this sort of thing with IoC and scripting, and I found
ClassWorlds (http://classworlds.codehaus.org) an excellent solution to
this kind of sandboxing. It can be achieved with URL classloaders, but
rapidly gets unmanageable.

I never carried the project much beyond experimental, so feel free to
reuse anything that's worth it: http://roscopeco.co.uk/moxy. (CVS is
discontinued - source distributions can be downloaded from the site). It
has numerous examples of using classworlds, including advanced package /
class import / export config and stuff.

 

[Thomas Hawtin]

From reading as much as I could in one sitting while paying attention, it
seems that what I would need is to tailor the

/3.1.9 java.lang.RuntimePermission/

To deny most everything. Does this sound close? The problem with the word
"security" in java is that it is such a broad topic and I'm having trouble
seeing the forest.

For a concrete example, you might want to look at the Tomcat source code.

When you write code that is called through doPrivileged, make sure
malicious code cannot supply you with subclassed objects that do evil
things. You are partially protected in that the effective privileges are
the intersection of the domains on the stack, above the doPrivileged. In
practice things can get messier than that.

One thing to be wary of is that the default policy for reflection allows
access to private methods and fields of classes loaded by the same class
loader. So if you write code that uses reflection to access methods or
fields, be very careful about what can call it.

Even in Java, writing secure code is something the very best programmers
can very easily screw up (even me).

Tom Hawtin