JBossDeveloper

 

"adrian@jboss.org" wrote:

An alternative solution is to change the way the VFSClassLoaderPolicy determines
the code source. i.e. instead of returning the vfs url we could hack it to return
a normal url.

...

An alternative solution would be to allow you to specify the codeSourceURL to use
for the classloader as a parameter when you create it.

I just tried a third alternative which is to delay the installation of the policy and
security manager and make it run in new security.xml bootstrap file.

This does work, I've committed it, obviously haven't enabled it by default
so committing it isn't a problem. :-)

To enable it change conf/bootstrap.xml

 <url>classloader.xml</url>
+ <url>security.xml</url>
 <url>aop.xml</url>

But there's some issues that need resolving.

1) POLICY FILE

You need to create a proper security policy file. The one I added
in server/xxx/conf/java.policy gives everybody all permissions.

I got as far as this:

grant codebase "file:/home/ejort/development/jboss-head/build/output/jboss-5.0.0.GA/bin/run.jar" {
 permission java.security.AllPermission;
};

grant codebase "file:/home/ejort/development/jboss-head/build/output/jboss-5.0.0.GA/lib/-" {
 permission java.security.AllPermission;
};

grant codebase "vfszip:/home/ejort/development/jboss-head/build/output/jboss-5.0.0.GA/lib/-" {
 permission java.security.AllPermission;
};

But there's other code in deployers and deploy that needs to have
the AllPermission. The default policy also needs defining to have
sensible rights.

2) The above shows an annoying feature.
We access things in JBOSS_HOME/lib using both the file: and vfszip urls
depending on whether the jars are loaded by the NoAnnotationURLClassLoader
or a VFSClassLoaderPolicy.

3) I could change the file: urls above to use the system properties,
but not the vfszip url. We don't have system properties for the vfs versions
of the urls.

4) There's some issue at shutdown where I try to uninstall the security manager
that I haven't investigated.

19:37:51,453 WARN [StartStopLifecycleAction] Error during stop for SecurityPolicy
java.security.AccessControlException: access denied (java.lang.RuntimePermission setSecurityManager)
 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 at java.security.AccessController.checkPermission(AccessController.java:427)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
 at java.lang.System.setSecurityManager0(System.java:253)
 at java.lang.System.setSecurityManager(System.java:245)
 at org.jboss.system.server.security.SecurityPolicy.stop(SecurityPolicy.java:97)

I guess the shutdown hooks run with different rights so it needs to be a
privileged block?

The actual implementation is fairly trivial

public class SecurityPolicy
{
 /** Whether to install the security manager */
 private SecurityManager securityManager;

 /** The policy url */
 private URL policyURL;

 /**
 * Get the securityManager.
 *
 * @return the securityManager.
 */
 public SecurityManager getSecurityManager()
 {
 return securityManager;
 }

 /**
 * Set the securityManager.
 *
 * @param securityManager the securityManager.
 */
 public void setSecurityManager(SecurityManager securityManager)
 {
 this.securityManager = securityManager;
 }

 /**
 * Get the policyURL.
 *
 * @return the policyURL.
 */
 public URL getPolicyURL()
 {
 return policyURL;
 }

 /**
 * Set the policyURL.
 *
 * @param policyURL the policyURL.
 */
 public void setPolicyURL(URL policyURL)
 {
 this.policyURL = policyURL;
 }

 @Start
 public void start()
 {
 if (policyURL != null)
 System.setProperty("java.security.policy", policyURL.toExternalForm());
 Policy.getPolicy().refresh();

 if (securityManager != null)
 System.setSecurityManager(securityManager);
 }

 public void stop()
 {
 if (securityManager != null)
 System.setSecurityManager(null);
 }
}

with xml config

 <bean name="SecurityPolicy" class="org.jboss.system.server.security.SecurityPolicy">
 <property name="securityManager"><javabean xmlns="urn:jboss:javabean:2.0" class="java.lang.SecurityManager"/></property>
 <property name="policyURL">${jboss.server.config.url}/java.policy</property>
 </bean>

I guess for management purposes, it would be better to have the policies
defined directly in that xml using our own policy implementation?
e.g. being able change policies from the profile service or management console?

NOTE: The above java.policy gets passed the aop problem you had Anil
but then fails on the binding manager because I hadn't given any permissions
to the service binding manager that lives in the shared libs (currently server/lib)

19:37:49,508 ERROR [AbstractKernelController] Error installing to Start: name=SystemPropertyBinder state=Create
java.security.AccessControlException: access denied (java.util.PropertyPermission jboss.messaging.connector.bisocket.port write)
 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 at java.security.AccessController.checkPermission(AccessController.java:427)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
 at java.lang.System.setProperty(System.java:699)
 at org.jboss.services.binding.SystemPropertyBinder$1.run(SystemPropertyBinder.java:68)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.jboss.services.binding.SystemPropertyBinder.start(SystemPropertyBinder.java:64)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
 at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
 at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
 at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54)

Which brings up the question whether the bootstrap files should be looking
at the shared lib folder and if so whether we should move more jars
from /lib into it.

 

"david.lloyd@jboss.com" wrote:

If you make the stop() method run privileged, won't you make it kind of easy to defeat the security manager (by simply undeploying the bean, or even just getting the bean by name, or creating an instance of it, and manually calling stop() on it from hostile code)?

That's a different issue. We already said that we need a permission
within the MC that controls who can inject/install what into what or who can
invoke on what through the kernel bus.

Currently there's no fine-grained permission, only one big permission
on whether you can access the kernel(controller).

Ales do you have a JIRA for that? Or have you already done it without me
noticing as usual? ;-)