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
configurations.
--
John
