db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Wed, 06 Feb 2008 18:09:09 GMT
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: 

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 

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.


View raw message