db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen" <John.Embret...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Wed, 06 Feb 2008 20:30:20 GMT
Rick Hillegas wrote:

> Thanks to Dan and John for the continuing discussion.

> It may be helpful to frame the discussion in terms of the following roles:
> VM-Admin - This is the account which starts up the VM which is running 
> Derby.
> JMX-Admin - This is a person who is authorized to run a tool like 
> jconsole against the VM which is running Derby. This person could be 
> running JMX locally or remotely.
> 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.
> OtherApp-Admin -  This is a person who configures another application 
> which runs in the same VM as Derby.
> In order to use JMX to monitor/configure Derby (and other applications), 
> I think that the following is true:
> DerbyNet-Admin => JMX-Admin
> Engine-Admin => JMX-Admin
> DB-Admin => JMX-Admin
> OtherApp-Admin => JMX-Admin
> Are there other relationships among these roles? In particular, it is 
> not clear to me that "VM-Admin => JMX-Admin".

I am under the impression that the VM-Admin is the master of JMX
configuration, setup of authentication and authorization etc, so I
believe it is safe to assume that VM-Admin => JMX-Admin. There may be
exceptions that I am not aware of, though.

> I think that it would be unfortunate if OtherApp-Admin had the ability 
> to read/write Derby properties. I'm not smart enough to understand the 
> implications of exposing these properties but I am paranoid that any 
> information is a potential handle which an attacker could exploit. If 
> the policy file doesn't grant OtherApp the right to read Derby 
> properties, then I suspect that we should not give that right to 
> OtherApp-Admin. I have particular misgivings about the 
> derby.authentication.provider property since knowing its value gives an 
> attacker a big clue about how to crack Derby's authentication.

Right, I thought it was possible to tune the exposure of
system properties using a security policy, but I'm not sure...
Configuring fine-grained authorization for the JMX services is also
possible. I assume that whoever controls the JMX services in the VM may
decide not to let OtherApp-Admin access the MBean server, but this of
course depends on how OtherApp-Admin is defined and authenticated.

> I also think it would be unfortunate if a DB-Admin could view or set the 
> properties which belong to the DerbyNet-Admin or Engine-Admin. Again, 
> I'm not smart enough to know which properties will turn out to be useful 
> for an attack.

As long as DB-Admin => JMX-Admin, that is true with our current design /
implementation. We may be able to implement some kind of elaborate and
fine-grained authorization system for our Management Service which can
handle this kind of situation. However, perhaps the moral here is: Do
not store sensitive information as system properties.

> It would be disappointing if any JMX-Admin could view the system 
> properties set by the VM-Admin. If that is true, I guess we just have to 
> deal with the consequences. Perhaps we could lobby to have this hole 
> closed.

Again, this may depend on how JMX authentication and authorization is
configured by the VM-admin. I have only tried to access MBeans on
localhost or remotely with authentication/authorization disabled, in
which case the JMX-admin is in fact able to read all system properties
(not set them). Not sure how easy it is to control this with other JMX


View raw message