db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "JMXSecurityExpectations" by JohnHEmbretsen
Date Thu, 14 Feb 2008 13:03:34 GMT
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'''?
  

Mime
View raw message