Parents: DerbyProposals, DerbyJMX

JMX Security Expectations

Security expectations for the JMX Management and Monitoring features added by DERBY-1387.

Note: (Feb 2008) This page will be in a volatile state for a while, as terminology and concepts are discussed, and solutions being developed, so there is no guarantee that all the text on this page is 100% consistent at all times.

Overview

This is an effort to track and summarize conclusions from discussions on the derby-dev mailing list and in Jira regarding JMX security in Derby.

Relevant background information is available in Jira and the mail archives, including:

Terminology

It may also be helpful to frame the discussion in terms of the following roles (extracted from mail thread #1 above):

Security Expectations

For the first revision of the JMX features, Derby's JMX features can either be enabled or disabled at system startup only. The default is: disabled. As this feature set develops, it may become possible to enable and/or disable the Derby JMX service at runtime, also after startup.

When the Derby system starts, and Derby's JMX features are enabled, and sufficient JMX support is available in the JVM running Derby, then Derby will establish a Management Service (JMX Agent) by (among other things) creating/retreiving an MBeanServer. MBeans must be registered with this MBeanServer in order to become accessible to valid JMX users.

The following paragraph sums up the community's expectations with regards to tDerby's JMX features:

A valid JMX user (a user able to connect via JMX to Derby's MBeanServer) must not be able to access information or perform operations that would otherwise be restricted by Derby's existing security mechanisms (authentication, authorization, Security Manager, etc.).

Summarized, the main issues that need to be sorted out are:

Credentials supplied during any kind of authentication process may not be accessed or be reused by another JMX user. Every JMX user/client must provide credentials if authentication is enabled, in order to access sensitive parts of the Derby system and/or a database.

Proposal - MBean Access Control - Proposal

Require that every action on an MBean (read attribute, write attribute, operation) undergoes at least one single authorization check in addition to any implicit JMX management permission checks (e.g. invoke permission on a specific MBean operation is an implicit check). The authorization check is one of:

Java security manager permissions would be modeled on java.lang.management.ManagementPermission which controls permissions for controlling and monitoring the jvm itself. So while a JMX client may be able to see MBeans that monitor the JVM it cannot get useful information of out them unless it has ManagementPermission("monitor").

Derby could have similar actions added to o.a.d.security.SystemPermission and DatabasePermission, e.g. monitor, control (or with better names).

Note it is not required that any permission check be in the MBean code itself, it can be in the underlying code that implements the functionality.

<!> Note that this proposal does not exactly match the security expectations described for the various MBeans below. E..g this proposal allows control over information returned by VersionMBean, whereas the section below allows any user to see VersionMBean's information.

Examples

New System Permissions

New actions to be added to Derby's permission class org.apache.derby.security.SystemPermission.

Could also have these:

May not be worth it as it's just as easy to specify multiple permissions in the policy file and having the single value implies others may cause issues when a new class is added, e.g. replicationControl. Would an existing policy file with SystemPermission("control") automatically gain replicationControl?

New Database Permissions

New actions to be added to Derby's permission class org.apache.derby.security.DatabasePermission.

Notes on new permissions

Exact use for these various permissions may become clear as attributes and operations are added to MBeans (and new MBeans added).

Some care may be needed with database permissions, to have a clear consistent story as to if DatabasePermission("monitor") is required or just database authentication and grant/revoke.

Suggested MBeans

Short descriptions of suggested MBeans and the security expectations associated with them (partly outdated).

VersionMBean

SystemMBean

NetworkServerControlMgmtMBean

DatabaseMBean

JMX Security setups

Local JMX

A jvm may be setup to automatically provide local jmx access. In this case the OS user running the client must match the OS user that started the jvm being monitored. JMX authentication and access level does not apply here.

No Security Manager (local)

Security Manager (local)

Remote JMX

Explicit actions are required by the JVM admin to:

So if remote mangagement is enabled then by default it is authenticated and uses SSL.

No Security Manager (remote)

Security Manager (remote)

Installing a security manager should be recommended if enabling remote JMX monitoring.

Notes/Issues

JMXSecurityExpectations (last edited 2009-09-20 22:12:47 by localhost)