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 DanDebrunner
Date Tue, 19 Feb 2008 19:47:44 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 DanDebrunner:
http://wiki.apache.org/db-derby/JMXSecurityExpectations

------------------------------------------------------------------------------
  
  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`) should in
general 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.).'''''
+ '''''A valid JMX user (a user able to connect via JMX to Derby's `MBeanServer`) must not
( <!>  WAS: should in general 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''
@@ -81, +81 @@

  
  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 - Access Control - Proposal ===
+ 
+ Require that every action on an MBean (read attribute, write attribute, operation) undergoes
a 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`, 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 would require `SystemPermission("monitor")`
+  * Setting attributes on a system MBean would require `SystemPermission("control")`
+  * Shutdown method on a network server control MBean would require `SystemPermission("shutdown")`
(from DERBY-2109)
+  * Getting attributes on a database MBean require `EXECUTE` on `SYSCS_GET_DATABASE_PROPERTY`.
+  * Setting attributes on a database MBean requires `EXECUTE` on `SYSCS_SET_DATABASE_PROPERTY`.
  
  === Suggested MBeans ===
  

Mime
View raw message