John Embretsen wrote:
Daniel John Debrunner wrote:
What would be the issue with getting access to those mbeans without
authentication? Just trying to understand the concern.
Dan.
As currently implemented, via JConsole these MBeans allow anyone
with a valid account on the server machine
"any valid account on the server machine" - I don't think that's true.
In local jmx mode isn't it only the owner of the process can connect
to it using jmx?
Something like that. Actually, I think the default local security is
based on file permissions. That is, as long as we're using the
platform MBean server. See
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#local .
Not sure how this works if we create our own MBean
server/agent/connector, though.
[ And as currently implemented (according to your experiments) you
can't change the system properties using the system mbean. ]
The required permissions are added to the default policy file in the
patch, as described in the funcSpec. The reason this is failing
currently is the lack of a privileged block around the code setting
the system properties in the System MBean.
Not saying there isn't an area of concern here, but just trying to
nail down exactly how any mbean exposes a new security hole.
I think one can say that without mbeans there is no mechanism
provided by derby to read or set system properties when a security
manager is in place.
[an application could provide such a mechanism today unrelated to
Derby's security]
With these mbeans derby provides a mechanism for any validated jmx
user to read and set derby related system properties, though setting
properties required that the security manager grants that permission
to the derby mbean code.
Now is that a security hole?
It seems to me that as long as we're not bypassing the security
mechanisms that actually are in place to protect system properties
(the Java Security Manager), we're not doing any harm.
With JMX enabled on the JVM level (regardless of Derby's JMX support),
you are able to read all system properties anyway, as a valid JMX user
on a local or remote machine.
On a local machine, given that you have the required file system
permissions, you don't even have to enable JMX to do so (with Sun's
newer JVMs at least).
I have not tried the JMX patch together with the System Privileges
patch, so I cannot tell at this point how the two will work together.
Thanks to Dan and John for the continuing discussion.
I don't know who is authorized to run jconsole locally. It is also
possible to run jconsole remotely:
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#jconsole_remote
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 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.
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.
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.
Regards,
-Rick
