Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Thu, 14 Feb 2008 13:03:34 -0000
Message-ID: <20080214130334.18603.47882@eos.apache.org>
Subject: [Db-derby Wiki] Update of "JMXSecurityExpectations" by JohnHEmbretsen

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by JohnHEmbretsen:
http://wiki.apache.org/db-derby/JMXSecurityExpectations

------------------------------------------------------------------------------
  
  == 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''.
+ 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.
  
- Credentials supplied during authentication may not be accessed or be reused by another JMX user. Every JMX user/client must provide credentials if authentication is enabled.
+ 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 system.
  
  After system startup, the following MBeans may be registered with the `MBeanServer` and thus enabled:
  
+ === Suggested MBeans ===
  
- === VersionMBean ===
+ Short descriptions of suggested MBeans and the security expectations associated with them.
  
+ ==== 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.
+  * All ''Attributes'' are available to all valid JMX users (read-only).
   * No ''Operations'' are defined in this MBean.
  
- === SystemMBean ===
+ ==== SystemMBean ====
  
+  * Available (enabled) on system startup if Derby JMX is enabled.
-  * Provides access to Derby system settings and other information on the system level in Derby. This is handled by including ''Attributes'' in the MBean. A single ''Attribute'' may defined as '''read-only''' or '''readwrite'''.
+  * 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).
-  * Provides an MBean operation, `bootDatabase(url)`, which boots a given database.
-  * May be enabled only if system-wide authentication ('''derby-authc''') is ''disabled'' in Derby (default),
-  
-    OR
- 
-    if system-wide authentication ('''derby-authc''') is ''enabled'' in Derby 
-      AND 
-    the JMX user has passed '''jmx-authc''' (and '''jmx-authr''')
-      AND
-    the JMX user has passed '''derby-authc'''
- 
-  * 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.
+  * 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 ===
+ ==== NetworkServerControlMgmtMBean ====
  
+  * Available (enabled) on server startup if Derby JMX is enabled.
-  * Provides access to the `NetworkServerControl` API and server-related settings.
+  * Provides access to the `NetworkServerControl` API, e.g. settings or actions.
-  * Some settings are read-only, others are readwrite.
+  * Some settings are ''read-only'', others are ''readwrite''.
   * Includes ''Operations'' such as `ping()`, `traceConnection(...)` and `shutdown()`.
-  * Same enabling policy as '''SystemMBean'''.
-  * ''Operation'' `shutdown()` may be restricted by a Java security policy, in which case a valid JMX user without the sufficient privileges should not be allowed to shut down the Network Server using this Operation. 
-    This requires integration with features developed with [https://issues.apache.org/jira/browse/DERBY-2109 DERBY-2109] (System Privileges).
+  * 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 ===
+ ==== 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''.
-  * A new '''DatabaseMBean''' will be created for each booted database. Such MBeans will be enabled automatically if '''*-authc''' and '''db-authr''' is disabled. /!\ How are the beans enabled if '''*-authc''' and '''db-authr''' are enabled? How can Derby code check the state of jmx-authc? Maybe this is using enabled incorrectly? If jmx is running then DatabaseMBean should be enabled, not all jmx-users may be able to use the bean, but it will still be enabled.??
+  * 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?
+  * 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`?
  
  
  == 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. 
-  * '''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.
+     * /!\ ''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.''
-  * more fine-grained authorization (per-operation, per-attribute) would probably be nice. But are the above enabling-policies too restrictive?
-  * how to perform '''derby-authc''' checks without connecting to a database? /!\ ''What database operations do not need a connection?''
+       * 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 [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?
   * do we need a ''delegating MBean'', controlling when to enable/disable other "sensitive" MBeans such as '''SystemMBean''' and '''NetworkServerControlMBean'''?