8.3 JMX Permissions

Version 1.1 of the JMX specification defines a new permission: MBeanServerPermission . In addition, MX4J defines two new permissions to address the security exposures described earlier. MBeanServerPermission and MBeanTrustPermission extend java.security.BasicPermission and represent "named" permissions that you either have or don't have. MBeanPermission , the other new MX4J permission, extends java.security.Permission and allows you to specify a target, the MBean(s) to which access is being granted, and the action (i.e., what you're allowed to do to the target MBean). Each of these permissions is described in more detail in Sections 8.3.1 through 8.3.3.

8.3.1 MBeanServerPermission

MBeanServerPermission controls access to the methods of MBeanServerFactory . Its associated target name is the name of the method to which access is being granted. Table 8.2 describes each of MBeanServerPermission 's target names .

Access to MBeanServerFactory makes it easy to attack your application's management facilities. For example, an attacker could mount a denial-of-service attack by simply finding and releasing the application's MBeanServer(s), rendering the MBeanServer(s) unmanaged and unmanageable, at least by JMX. Therefore, you should carefully control access to MBeanServerFactory .

8.3.2 MBeanTrustPermission

MBeanTrustPermission controls which MBeans can be registered with the MBeanServer. It has a single target name, "register," associated with it.

MBeanTrustPermission allows you to make policy statements like, "MBeans signed by Tivoli may be registered with the MBeanServer" or "MBeans that were loaded from /opt/ibm/mbeans may be registered with the MBeanServer." Note that these statements are not saying that code signed by Tivoli or loaded from /opt/ibm/mbeans may call the MBeanServer's registerMBean() method. Instead, the statement is that we allow only MBeans signed by Tivoli or loaded from /opt/ibm/mbeans in the MBeanServer's registry.

Table 8.2. Target Names Recognized by MBeanServerPermission

Target Name	What the Permission Allows
MBeanServerFactory.createMBeanServer	Creation of an MBeanServer retaining a reference to the new MBeanServer within the factory
MBeanServerFactory.newMBeanServer	Creation of an MBeanServer
MBeanServerFactory.findMBeanServer	Lookup of one or all of the MBeanServers created by the factory
MBeanServerFactory.releaseMBeanServer	Removal of one of the MBeanServers created by the factory

MBeanTrustPermission addresses the "untrusted MBean registration" exposure described in Table 8.1. It allows us to be sure, for example, that the MBeans being used to manage the Cisco routers in our network are the MBeans that Cisco shipped with those routers and not some look-alike MBeans that an attacker managed to slip into our classpath ahead of the Cisco MBeans.

8.3.3 MBeanPermission

MBeanPermission controls access to MBeans. An MBeanPermission instance must specify the MBean(s) it applies to and the actions allowed on those MBeans. Any MBean that a particular instance of MBeanPermission applies to is called the permission's target and is specified via a string, called the target name, composed of the target MBean's class name, the name of one of the target MBean's attributes or operations, and an object name. For example, suppose we have an MBean whose class name is net.jnjmx.ch8.Demo , with a single attribute ( Title ) and the operation start . If an instance of the Demo MBean is registered under the object name jnjmx:id=FooOne,ch=8 , then the MBeanPermission target name for the Title attribute is

 net.jnjmx.ch8.Demo#Title[jnjmx:id=ExampleOne,ch=8] 

and the MBeanPermission target name for the start operation is

 net.jnjmx.ch8.Demo#start[jnjmx:id=ExampleOne,ch=8] 

In general, MBeanPermission target names have the form

 <classname>#<attribute/operation>[<objectname>] 

The attribute/operation and objectname components are optional.

Wildcards (i.e., the asterisks ) may be used in the classname and attribute/operation components of the target name (for example, see Table 8.3). ObjectName patterns may be used in the target name's object name component.

Table 8.3. Examples of Wildcards in MBeanPermission Target Names

Target Name	Explanation
net.jnjmx.ch8.*#start	Designates all the start operations of any MBean whose class name begins with "net.jnjmx.ch8".
net.jnjmx.ch8.Demo#*	Designates all of the net.jnjmx.ch8.Demo MBean's attributes and operations.
net.jnjmx.ch8.*#*[jnjmx:*]	Designates all of the attributes and operations associated with any MBean whose name begins with "net.jnjmx.ch8" and that is registered in the jnjmx domain.

The actions supported by MBeanPermission are described in Table 8.4.

Table 8.4. MBeanPermission Actions

Action	What the Action Allows
addListener	Addition of notification listeners, either directly (i.e., via an object reference to the MBean) or via the MBeanServer's addNotificationListener() method.
getAttribute	Retrieval of the value of an MBean's attribute.
getMBeanInfo	Retrieval of the MBean's metadata.
newMBean	Creation of a new instance of the MBean in the MBeanServer via the MBeanServer's createMBean() method.
invokeOperation	Invocation of an operation on the MBean via the MBeanServer's invoke() method.
registerMBean	Registration of an instance of the MBean via the MBeanServer's registerMBean() method.
removeListener	Removal of notification listeners, either directly (i.e., via an object reference to the MBean) or via the MBeanServer's removeNotificationListener() method.
setAttribute	Setting the value of an MBean's attribute.
unregisterMBean	Deregistration of an instance of the MBean via the MBeanServer's unregisterMBean() method.
*	All of the above.

The security exposures associated with some of these actions are obvious. For example, given the ability to unregister MBeans, an attacker's code could remove MBeans that provide vital data or control to a management application. With permission to create and register new MBeans, an attacker could "spoof" legitimate MBeans by substituting rogue versions of those MBeans. Other exposures are more subtle. How much harm can be done by adding an additional listener? Perhaps quite a bit if the JMX notifications that the new listener receives contain sensitive data. Likewise, although access to an MBean's metadata, via the getMBeanInfo() method, may seem innocuous , it may provide an attacker with information necessary to mount a successful attack against the system.