db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3462) 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
Date Fri, 14 Mar 2008 15:36:25 GMT

    [ 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.


Mime
View raw message