Differences between revisions 18 and 19
Revision 18 as of 2008-02-22 07:59:52
Size: 21339
Comment: Some clarifications and temporary notes...
Revision 19 as of 2009-09-20 22:12:47
Size: 21369
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
~-Parents: DerbyProposals, ["DerbyJMX"]-~ ~-Parents: DerbyProposals, [[DerbyJMX]]-~
Line 5: Line 5:
Security expectations for the JMX Management and Monitoring features added by [https://issues.apache.org/jira/browse/DERBY-1387 DERBY-1387]. Security expectations for the JMX Management and Monitoring features added by [[https://issues.apache.org/jira/browse/DERBY-1387|DERBY-1387]].
Line 9: Line 9:
[[TableOfContents]] <<TableOfContents>>
Line 13: Line 13:
This is an effort to track and summarize conclusions from discussions on the derby-dev mailing list and in [https://issues.apache.org/jira/browse/DERBY-1387 Jira] regarding JMX security in Derby. This is an effort to track and summarize conclusions from discussions on the derby-dev mailing list and in [[https://issues.apache.org/jira/browse/DERBY-1387|Jira]] regarding JMX security in Derby.
Line 16: Line 16:
 * [https://issues.apache.org/jira/browse/DERBY-1387 DERBY-1387] (includes a functional specification)
 * [https://issues.apache.org/jira/browse/DERBY-2109 DERBY-2109]
 * [http://www.nabble.com/-jira--Created%3A-%28DERBY-1387%29-Add-JMX-extensions-to-Derby-td4770244.html Mail thread #1]
 * [http://db.markmail.org/message/v6npsxpyfrzxchiy?q=list:org%2Eapache%2Edb%2Ederby-dev Mail thread #1.1] (Protecting system properties)
 * [http://db.markmail.org/message/s7eqlhz6ydrufatl?q=list:org%2Eapache%2Edb%2Ederby-dev Mail thread #1.2] (JMX meeting system authorization)
 * [http://www.nabble.com/JMX-Access-Control-Proposal-td15616493.html Mail thread #2] (JMX Access Control proposal discussion)
 * [[https://issues.apache.org/jira/browse/DERBY-1387|DERBY-1387]] (includes a functional specification)
 * [[https://issues.apache.org/jira/browse/DERBY-2109|DERBY-2109]]
 * [[http://www.nabble.com/-jira--Created%3A-%28DERBY-1387%29-Add-JMX-extensions-to-Derby-td4770244.html|Mail thread #1]]
 * [[http://db.markmail.org/message/v6npsxpyfrzxchiy?q=list:org%2Eapache%2Edb%2Ederby-dev|Mail thread #1.1]] (Protecting system properties)
 * [[http://db.markmail.org/message/s7eqlhz6ydrufatl?q=list:org%2Eapache%2Edb%2Ederby-dev|Mail thread #1.2]] (JMX meeting system authorization)
 * [[http://www.nabble.com/JMX-Access-Control-Proposal-td15616493.html|Mail thread #2]] (JMX Access Control proposal discussion)
Line 48: Line 48:
   * Note that in relation to JDBC connection requests (to a database) ''derby-authc'', if set, may be overridden by db-authc in certain configurations (see [http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html ''Precedence of properties'']).    * Note that in relation to JDBC connection requests (to a database) ''derby-authc'', if set, may be overridden by db-authc in certain configurations (see [[http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html|''Precedence of properties'']]).
Line 54: Line 54:
   * Note that even if set, this ''may'' be overridden by ''derby-authc'' in certain configurations, see [http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html ''protection of database properties''].    * Note that even if set, this ''may'' be overridden by ''derby-authc'' in certain configurations, see [[http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html|''protection of database properties'']].
Line 65: Line 65:
 * See also [http://www.nabble.com/JMX-Access-Control-Proposal-td15616493.html this E-mail thread] to clarify potential misunderstandings in the following text.  * See also [[http://www.nabble.com/JMX-Access-Control-Proposal-td15616493.html|this E-mail thread]] to clarify potential misunderstandings in the following text.
Line 70: Line 70:
  * '''Engine-Admin''' - This is the person who configures Derby's system-wide behavior. Probably this is the !DerbyNet-Admin. However, the discussion on [https://issues.apache.org/jira/browse/DERBY-2109 DERBY-2109] has presented a case for separating these two roles.   * '''Engine-Admin''' - This is the person who configures Derby's system-wide behavior. Probably this is the !DerbyNet-Admin. However, the discussion on [[https://issues.apache.org/jira/browse/DERBY-2109|DERBY-2109]] has presented a case for separating these two roles.
Line 161: Line 161:
   * If System Privileges ([https://issues.apache.org/jira/browse/DERBY-2109 DERBY-2109]) are enforced by Derby, then a valid JMX user cannot create a new database using the `bootDatabase(url)` Operation unless this user has sufficient privileges to do so.    * If System Privileges ([[https://issues.apache.org/jira/browse/DERBY-2109|DERBY-2109]]) are enforced by Derby, then a valid JMX user cannot create a new database using the `bootDatabase(url)` Operation unless this user has sufficient privileges to do so.
Line 230: Line 230:
 * how to (easily and correctly) enforce [http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html ''Precedence of properties''] and [http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html ''protection of database properties'']? Are there existing utility methods or other mechanisms for this?  * how to (easily and correctly) enforce [[http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html|''Precedence of properties'']] and [[http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html|''protection of database properties'']]? Are there existing utility methods or other mechanisms for this?

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

  • Let's simplify things by saying that MBeans have essentially two states: enabled or disabled

    • An enabled (registered) MBean is visible/accessible to any valid JMX user.

    • A disabled (unregistered) MBean is not visible/accessible any JMX user.

  • "Running Derby":

    • Running the Derby engine with Derby's JMX Management and Monitoring features enabled, using a JVM supporting all JMX features inclueded in J2SE 5.0. This includes, for example, running the Derby Network Server or Derby Embedded using a Java SE 6 JVM.
  • JMX user:

    • A user connecting to the JVM running Derby and thereby possibly Derby's Management Service through JMX, either VM-locally (from the same JVM), locally (from the same host as the host running Derby), or remotely (from a different host than the host running Derby). A "valid" JMX user is a user who is successfully authenticated by the system (this includes all JMX users when authentication is disabled).
  • JMX Authentication (jmx-authc):

    • A user trying to access Derby's JMX services may need to provide some kind of credentials (prove her identity) in order to connect to the MBeanServer. Whether or not to require JMX authentication is up to the VM-Admin.

    • If JMX Authentication is enabled then JMX Access is required. This is a simple authorization scheme (c.f. Derby's connection level authorization) that defines JMX authentication users as either readwrite or readonly. Note that finer grained authorization is provided by the policy file for the security manager. This access level seems to be enforced by the security manager.

      • readwrite can read and write attributes and invoke operations on MBeans.

      • readonly can only read attributes on MBeans.

  • JMX Authorization (jmx-authr):

    • Once authenticated, a user may be granted a certain set of rights to perform certain JMX-related actions (read/write attributes, invoke operations, register MBeans, etc.) through standard Java security manager permissions. When authorization is disabled by there not being a security manager on the jvm being monitored, any valid JMX user may use and access all services offered by the Management Service.
  • Derby system level authentication (derby-authc):

    • The system-wide property derby.connection.requireAuthentication is true.

    • Note that in relation to JDBC connection requests (to a database) derby-authc, if set, may be overridden by db-authc in certain configurations (see ''Precedence of properties'').

    • In some of the following text, different interpretations of this term seems to have been used. It may be necessary to reconsider this definition to avoid such issues.
  • Derby database level authentication (db-authc):

    • The database-wide property derby.connection.requireAuthentication is true.

    • Note that even if set, this may be overridden by derby-authc in certain configurations, see ''protection of database properties''.

    • In some of the following text, different interpretations of this term seems to have been used. It may be necessary to reconsider this definition to avoid such issues.
  • Derby database level connection authorization (db-authr):

    • A given user is authorized with either fullAcess (default), readOnlyAccess or noAccess privileges. This is defined by a number of the databse-wide properties

      • derby.database.defaultConnectionMode (the default defaultConnectionMode is fullAccess)

      • derby.database.fullAccessUsers

      • derby.database.readOnlyAccessUsers

  • * is a wildcard (for example, *-authc includes jmx-authc, derby-authc and db-authc).

  • See also this E-mail thread to clarify potential misunderstandings in the following text.

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

  • VM-Admin - This is the account which starts up the JVM which is running Derby. This user has full control of the VM.

  • DerbyNet-Admin - This is the person who configures Derby's network behavior.

  • Engine-Admin - This is the person who configures Derby's system-wide behavior. Probably this is the DerbyNet-Admin. However, the discussion on DERBY-2109 has presented a case for separating these two roles.

  • DB-Admin - This is a person who configures a particular Derby database - the Database Owner.

  • OtherApp-Admin - This is a person who configures another application which runs in the same VM as Derby.

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:

  • A (Derby) system admin (possibly including both VM-Admin, DerbyNet-Admin and Engine-Admin) should not necessarily have access to all databases booted in the system

  • A database admin (DB-Admin) should not necessarily be able to access system-level Derby settings.

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 permission
  • Database authorization (GRANT/REVOKE)

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

  • Get attribute methods on VersionMBean for the network server would require SystemPermission("serverMonitor")

  • Setting attributes on a system MBean would require SystemPermission("engineControl")

  • Shutdown method on a network server control MBean would require SystemPermission("shutdown") (from DERBY-2109)

  • Getting attributes representing database properties on a database MBean require EXECUTE on SYSCS_GET_DATABASE_PROPERTY.

  • Setting attributes representing database properties on a database MBean requires EXECUTE on SYSCS_SET_DATABASE_PROPERTY.

  • Getting non-database properties attributes would require DatabasePermission("monitor") for the specific database.

New System Permissions

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

  • SystemPermission("jmxControl") - ability to start and stop Derby's JMX management

  • SystemPermission("serverControl") - ability to control the network server and see sensitive information like host, port number

  • SystemPermission("serverMonitor") - ability to monitor the network server

  • SystemPermission("engineControl") - ability to control the engine (not sure of a use here yet)

  • SystemPermission("engineMonitor") - ability to monitor the engine (not sure of a use here yet)

Could also have these:

  • SystemPermission("control") - implies "jmxControl,serverControl,engineControl"

  • SystemPermission("monitor") - implies "serverMonitor,engineMonitor"

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.

  • DatabasePermission("control") - ability to see control the database and see sensitive information (e.g. authentication settings, database name)

  • DatabasePermission("monitor") - ability to see monitoring information about the database (e.g. current connection count).

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

  • Available (enabled) on system startup if Derby JMX is enabled.
  • Displays version information from the running Derby instance.
    • There may be several instances of this MBean, where each instance reports version information about a certain part of the system (e.g. a specific jar file derby.jar or the Derby engine).
  • Will be enabled "always".
  • All Attributes are available to all valid JMX users (read-only).

  • No Operations are defined in this MBean.

SystemMBean

  • Available (enabled) on system startup if Derby JMX is enabled.
  • Provides monitoring and management access to Derby system settings. This is provided by including Attributes in the MBean. A single Attribute may defined as read-only or readwrite.

  • Provides an MBean operation, bootDatabase(url), which boots a given database (subject to normal system and database access control - i.e. if Derby refuses a connection attempt using the URL supplied by the JMX user, the database should not be booted).

    • If System Privileges (DERBY-2109) are enforced by Derby, then a valid JMX user cannot create a new database using the bootDatabase(url) Operation unless this user has sufficient privileges to do so.

  • The availability of Attributes and Operations is subject to system-level access control.

    • If derby-authc is enabled, system settings should only be available to authenticated users.

    • Furthermore, any "active" Java Security Policy must be enforced if Derby is running under a Security Manager.
    • It should not be able to override existing system-wide authentication (derby-authc) or authorization (System privileges) checks by using JMX.

NetworkServerControlMgmtMBean

  • Available (enabled) on server startup if Derby JMX is enabled.
  • Provides access to the NetworkServerControl API, e.g. settings or actions.

  • Some settings are read-only, others are readwrite.

  • Includes Operations such as ping(), traceConnection(...) and shutdown().

  • The availability of Attributes and Operations is subject to system-level access control.

    • If derby-authc is enabled, sensitive system settings and actions should only be available to authenticated users.

    • Furthermore, any "active" Java Security Policy must be enforced if Derby is running under a Security Manager.
    • It should not be able to override existing system-wide authentication (derby-authc) or authorization (System privileges) checks by using JMX.

DatabaseMBean

  • Available (enabled) on database boot if Derby JMX is enabled.
  • One MBean instance per booted database.
  • Provides access to database settings and operations.
  • Settings may be read-only or readwrite.

  • The availability of Attributes and Operations is subject to database-level and possibly system-level access control.

    • If db-authc is enabled, sensitive database settings and actions should only be available to authenticated users.

    • If db-authr is enabled, sensitive database settings should not be readable to users with noAccess authorization.

    • If db-authr is enabled, sensitive database settings should not be writeable to users with noAccess or readOnlyAccess authorization.

    • Furthermore, any "active" Java Security Policy must be enforced if Derby is running under a Security Manager.
    • It should not be able to override existing system-wide authentication (derby-authc) or authorization (System privileges) checks by using JMX.

  • If any of *-authc are enabled, the JMX user must pass all authentication checks (jmx-authc, derby-authc, db-authc) that are enabled for this type of access (connecting to this particular database using this particular Derby system).

    • /!\ Why is derby-authc included here, to connect to a database derby-authc is not required, so why to administer it?

      • Isn't passing derby-authc required if it has been enabled programmatically, unless derby.database.propertiesOnly=true?

      • No, to connect to a database only database authentication is needed. (db-authc').

      • OK, it seems that we have been using different interpretations of db-authc (see mail thread #2 above). The terms should probably be redifined before updating these MBean descriptions.

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)

  • The local jmx client (running as the same OS user as the virtual machine) may perform any JMX client operation including accessing any MBean including reading its attributes, writing its updateable attributes and invoking its operations, registering and unregistering MBeans, controlling the virtual machine etc.
  • Since there is no security manager then any action that requires a specific permission (e.g. shutdown Derby )would be allowed as well.

Security Manager (local)

  • It seems as though the local jmx client can perform any JMX operation such as getting attributes, invoking operations, registering MBeans etc. (i.e. I'm guessing that when run as the local os user the permissions come from the fact it's jvm system code that is performing jmx operations).
  • The current access context has no Subject.
  • If some action on a Derby MBean requires some security permission then that will fail unless the permission has been granted to Derby's code. E.g. an operation that fetches the system propertry "derby.system.home" succeeds, but reading a property derby.jar does not have permission to read fails. Reading the system property successfully did not require a privilege block (I presume because the calling code (jmx) is system code and granted all permissions).

Remote JMX

Explicit actions are required by the JVM admin to:

  • Enable remote management via jmx (setting com.sun.management.jmxremote=true, com.sun.management.jmxremote.port)
  • Disable authentication (setting com.sun.management.jmxremote.authenticate=false)
  • Disable SSL for remote clients (setting com.sun.management.jmxremote.ssl=false)

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

No Security Manager (remote)

  • Any authenticated (or any user if there is no JMX authentication) remote jmx client may access any MBean including reading its attributes, writing its updatable attributes and invoking its operations.

Security Manager (remote)

  • Any authenticated remote jmx client is limited to its permissions in the policy file and its JMX access level. Permissions can be granted at a fine grained level on a per-JMXPrincipal basis. E.g. a JMXPrincipal could be given the permission only to read a single attribute from a single MBean with a given ObjectName.

  • If JMX authentication is not enabled then any user can connect via JMX and has all permissions related to MBean management.

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

  • If some action on a Derby MBean requires some security permission then that will fail unless the permission has been granted to Derby's code or the authenticated JMXPrincipal (when JMX authentication is enabled).

Notes/Issues

  • jmx-authc should be closely tied to derby-authc so that a user does not have to authenticate twice (or more) in order to use a system-level MBean.

    • /!\ Not sure if closely tied is the correct description here. At least it should be possible for JMX-users (which by definition have passes jmx-authc) to be in the set of valid Derby system adminstrators, thus allowing Derby system permissions granted to them.

      • Right. It would still be good if the system admin did not have to define users on both a JMX-level and Derby-level, but that could be something for future work. Not sure what description suits this best.
  • how to perform derby-authc checks without connecting to a database?

    • /!\ What database operations do not need a connection?

      • What about System operations? in order to "enable" certain system-level operations or attributes, a user should have to pass derby-authc, right?

  • how to (easily and correctly) enforce ''Precedence of properties'' and ''protection of database properties''? Are there existing utility methods or other mechanisms for this?

  • do we need a delegating MBean, controlling when to enable/disable other "sensitive" MBeans such as SystemMBean and NetworkServerControlMBean?

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