[
https://issues.apache.org/jira/browse/DERBY-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578702#action_12578702
]
John H. Embretsen commented on DERBY-3462:
------------------------------------------
I must admit it is not easy to follow all the commits going on in this area
(system permissions and JMX). I hope others are able to look at these changes
as well, eventually.
In the default server policy, the following is granted to derby.jar:
// Gives permission for jmx to be used against Derby but
// only if JMX authentication is not being used.
// In that case the application would need to create
// a whole set of fine-grained permissions to allow specific
// users access to MBeans and actions they perform.
permission org.apache.derby.security.SystemPermission "jmx", "control";
permission org.apache.derby.security.SystemPermission "engine", "monitor";
permission org.apache.derby.security.SystemPermission "server", "monitor";
Does this mean that these permissions serve no purpose if JMX authentication is
enabled? Or are these permissions needed in addition to any user-specific
fine-grained permissions in that case?
I have not studied the code in detail yet, but I'm trying to understand the
comments independently from that...
Regarding permission usage, I don't think I fully understand the reasoning
behind it, but I guess that is to be expected given the following sentence from
the wiki:
"Exact use for these various permissions may become clear as attributes and
operations are added to MBeans (and new MBeans added)."
For others trying to understand this, here are some notes (ramblings) I've made
that may of interest:
Control is defined as "Permission to perform control actions through JMX on
engine, server or jmx".
Monitor is defined as "Permission to perform monitoring actions through JMX on
engine and server".
Reading the following NetworkServerMBean attributes require the ("server",
"control") permission:
DrdaHost
DrdaPortNumber
DrdaSecurityMechanism
DrdaSSLMode
DrdaTraceDirectory
The rest of the actions require the "monitor" permission. Both permissions are
granted to the network server in the default policy.
I do understand that "control" is used for attributes that are deemed more
security sensitive than others. Intuitively, though, I would say that *all* the
current NetworkServerMBean actions are monitoring actions, not control actions,
but I guess I'll get over it...
I guess "control" seems more like a description of a role than a specific
action at this point.
If both permissions ("control" and "monitor") are included for the network
server in the default policy file, why don't we leave distinguishing between
sensitive actions and non-sensitive actions to the admin? Admins may have
different views of which actions are security sensitive and which are not... I
guess if JMX authentication is enabled this (fine-grained permission grants) is
still possible...
> 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.
