db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Tue, 05 Feb 2008 23:06:14 GMT
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> Daniel John Debrunner wrote:
>>>> Rick Hillegas (JIRA) wrote:
>>>>>     [ 
>>>>> https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565836#action_12565836

>>>>> ]
>>>>> Rick Hillegas commented on DERBY-1387:
>>>>> --------------------------------------
>>>>>
>>>>> I believe the reason that I was not able to connect at the end of 
>>>>> my experiment was this: the server was actually brought down. 
>>>>> Again, without presenting credentials, this seems like the wrong 
>>>>> behavior to me.
>>>>
>>>> Isn't that Derby's behaviour at the moment, shutting the network 
>>>> server down does not enforce authentication? Security enforcement 
>>>> should not be the role of the JMX mbeans.
>>>>
>>>> Dan.
>>> Right. I think there are at least two authentication issues here. One 
>>> is the current behavior of the network server (the bug which will be 
>>> addressed by Martin's work on DERBY-2109). The other issue is the 
>>> fact that the current DERBY-1387 patch lets you get your hands on the 
>>> server and system MBeans without presenting credentials. It's that 
>>> latter issue which I'm talking about here.
>>
>> 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?

> to view and change settings which 
> only the System Administrator can view and change today. That seems like 
> a security hole to me.

Which settings exactly? The network and System mbeans are setting system 
properties (I assume), which are not under the control of Derby's 
authentication and authorization? They are only under the control of 
Java permissions.

[ And as currently implemented (according to your experiments) you can't 
change the system properties using 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?

Dan.


Mime
View raw message