Policy Implementation for VFS

[anil.saldhana]

Adrian, you wanted to apply Java security permission checks to vfs deployments (deploy, undeploy etc).

Some possibilities are:

1) Use the current JACC policy implementation that is keyed in by a context id (which is essentially a string). So you can create a contextid that is the vfs url and create custom permissions that denote the controls that you want to apply.

2) We will need to extend the current DelegatingPolicy implementation (which is the JACC policy provider) to utilize VFS policy in addition to jacc.

Option 1 is the easiest. It has to be ensured that once the policy configuration is filled with permissions, a pc.commit needs to be called to make the policy get into action.

[anil.saldhana]

http://wiki.jboss.org/wiki/DelegatingPolicy

Some pseudocode:

Deployer:
String ctxID = "vfs:/xyz";

PolicyConfiguration pc = PolicyConfigurationFactory.getPolicyConfiguration(ctxID, false);

VFSDeployPermission vfsd = new VFSDP(xyz);
pc.addToRole("Administrator", vfsd);
pc.addToUnchecked()
...
pc.commit()

Enforcement:
Policy.getPolicy().implies(myvfsperm);

Reference:
http://java.sun.com/javaee/5/docs/api/javax/security/jacc/PolicyConfiguration.html

[adrian.brock]

I said the jacc stuff would be interesting, but the real issue is making
the policy file stuff understand the vfs urls.

The default implementation using system properties
http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html
won't understand the vfs urls because the VFS code isn't even in the classpath
when the server boots and reads the file.

[dmlloyd]

The default implementation using system properties
http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html
won't understand the vfs urls because the VFS code isn't even in the classpath
when the server boots and reads the file.

My understanding may well be flawed, but when I was researching this for secure classloading in Remoting, my conclusion was that the URLs need not be resolvable at load time; rather they are somehow compared against the ClassLoader's CodeSource (by way of the ProtectionDomain used to load each class) at the time the permission is checked, or possibly at the time the class is loaded. I think that as long as the VFS classloader is properly configuring the ProtectionDomain when loading classes, including the proper VFS URL for each class (using one of the ClassLoader.defineClass() methods which accepts ProtectionDomain), it should Just Work, even with the default policy.

[adrian.brock]

It didn't work when we tried an experiment with an njar url in 3.0.0.alpha

[dmlloyd]

Ah, I see. It's obvious now that I try it out: the policy file parser is literally constructing a URL instance during the parsing stage, which fails because the appropriate URL handler is missing.

So I guess the real question is: it the best solution to implement a custom policy interpreter that can handle arbitrary URIs, or to come up with a way to trick the URL protocol registry system to allow the URL handler to be "lazy-loaded"?

[anil.saldhana]

We can implement an alternative Policy Class implementation. But the flip side is that the configuration is done in lib/security/java.security file of the JDK.

[anil.saldhana]

Ah, I see. It's obvious now that I try it out: the policy file parser is literally constructing a URL instance during the parsing stage, which fails because the appropriate URL handler is missing.

So I guess the real question is: it the best solution to implement a custom policy interpreter that can handle arbitrary URIs, or to come up with a way to trick the URL protocol registry system to allow the URL handler to be "lazy-loaded"?

[url]http://java.sun.com/j2se/1.5.0/docs/api/java/security/ProtectionDomain.html#ProtectionDomain(java.security.CodeSource,%20java.security.PermissionCollection,%20java.lang.ClassLoader,%20java.security.Principal[])[/url]

CodeSource needs an URL instance for instantiation.

[dmlloyd]

Yes, that's what I said.

[dmlloyd]

I guess the simplest way to solve the problem is to have bogus URL handlers defined on the boot classpath for all the URL schemes we want, and then once the container is booted far enough, it can install a URLStreamHandlerFactory that loads the "correct" handler factories from then on. This will work around the check that the URL constructor does.

[dmlloyd]

A quick mockup test shows this is at least feasible. Throughout the entire verification process the URLStreamHandler.connect() method is never called so it doesn't have to be a "real" handler in order for security checks to work.

[anil.saldhana]

I guess the simplest way to solve the problem is to have bogus URL handlers defined on the boot classpath for all the URL schemes we want, and then once the container is booted far enough, it can install a URLStreamHandlerFactory that loads the "correct" handler factories from then on. This will work around the check that the URL constructor does.

Behavior consistent across all JVM implementations?

[dmlloyd]

It should be... the policy parser won't try to open the URL directly because the actual URL might not be valid (in terms of the classloader) - it might contain a wildcard character for instance. And the security manager won't try to open the class file at check time becase (a) the class is already loaded, (b) it would be a performance nightmare, and (c) it would cause intermittent application failures if it was e.g. an HTTP url.

[anil.saldhana]

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102673

Additional discussion is happening on this thread...