| daniel@franke.name 2005-02-19, 3:58 am |
| I'm writing a Java application which needs to perform trusted
operations, but will run plug-ins containing untrusted code. For added
security, I'd like to be able to define a policy which places some
limitations on the trusted code, but the default system class loader
with the default policy will assign inappropriate protection domains to
built-in code. Using static policy file for the entire system, without
extending java.security.Policy, may or may not be sufficiently flexible
for my needs. I know there are several ways around this, but I'd like
the group's opinion on which one is the least kludgy.
1. Set policy.provider to my custom policy class.
Pros: Gives me complete control.
Cons: Requires screwing around with the user's configuration files and
bootstrap classpath. Syntax for appending to the bootstrap classpath
is platform-dependent.
2. Write a static policy file to handle built-in classes only. Replace
it with my custom policy at runtime.
Pros: Should result in needing a relatively simple extension of Policy.
Cons: Ugly. Requires passing extra command-line arguments to the java
interpreter.
3. Write my own class loader which assigns appropriate
ProtectionDomains and set java.system.class.loader.
Pros: Elegant.
Cons: Requires passing extra command-line arguments to the java
interpreter.
4. Have my policy class override getPermissions(ProtectionDomain).
Check if the ProtectionDomain in question was assigned by the system
class loader. If so, substitute a more approrpriate
PermissionCollection.
Pros: Requires nothing extra on the command line.
Cons: Ugly.
|