[
https://issues.apache.org/jira/browse/DERBY-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578811#action_12578811
]
Daniel John Debrunner commented on DERBY-3462:
----------------------------------------------
At a higher level with the basic server policy (the one installed automatically
when the server is run through NetworkServerControl.main) we have a number of
choices, all controlled through permissions we grant in the basic policy.
Here's the list of the choices with the current answer for trunk:
Do we allow the basic policy to ...
A) Register JMX Mbeans - YES
B) Allow Derby monitoring capabilities - YES
C) Allow Derby control capabilities - YES
D) Allow local (via process id) jmx - YES
E) Allow remote jmx - YES
F) Allow authenticated jmx - NO
G) Allow JVM monitoring - not sure - nothing is done to enable or disable it by
derby.
H) Allow JVM control - not sure - nothing is done to enable or disable it by
derby.
My decisions here are based off a discussion we had when you (John) added the
permissions to register MBeans to the basic policy, I asked something along the
lines of what scenarios were you trying to support.
I think this ends up with a useful set of jmx functionality when using local
jmx (process id based) monitoring (D=YES). Since this can only be performed by
the same OS user that started the server having the full JMX control (C=YES)
does not introduce any security concerns.
E=YES may pose concerns, as with F=NO, it's only unauthenticated JMX that is
supported. The trouble is that we cannot tell the difference (from the Derby
code point of view) between local jmx and remote jmx no authentication. Thus if
D=YES then E=YES. However it is a conscious decision for an application to
start remote un-authenticated JMX monitoring. If they make that choice, it's
their problem.
F=NO is because the only way it would work would be to grant all permissions to
all JMXPrincipals, which seems way too open to me. The only control an
application could have is through JMX authorization, which would limit JMX
users to be read-write (get & set attributes, invoke operations) or read-only
(get attributes only).
G,H - I only just thought about :-)
> Require new permissions in o.a.d.security.SystemPermission to allow control
> to Derby's JMX management and to ensure information is not leaked through JMX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3462
> URL: https://issues.apache.org/jira/browse/DERBY-3462
> Project: Derby
> Issue Type: Sub-task
> Components: JMX, Security
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> Plan is to implement proposal defined in:
> http://wiki.apache.org/db-derby/JMXSecurityExpectations#head-de15a7e9d474784775933965fe963b6ac46e7ad0
> E.g.
> jmxControl for the ability to call the operations on ManagementMBean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
