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.
