db-derby-dev mailing list archives

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


-- 
John


Mime
View raw message