[Bug 66125] New: JMProxy - enhance security restrictions

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66125

            Bug ID: 66125
           Summary: JMProxy - enhance security restrictions
           Product: Tomcat 10
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Manager
          Assignee: dev@tomcat.apache.org
          Reporter: funkman@apache.org
  Target Milestone: ------

Use case: Allow an admin to restrict the scope of available queries for finding
beans. Also allow the scope to be restricted per operation.

Done by allowing for a servlet init parameter or a servlet context init param.
Naming of the parameter is the same (except the context version has a
"JMXProxyServlet." prefix to the name) By allowing servlet context init param,
then the manager.xml context file can be updated instead of the more risky
(when versions update) server admin change of web.xml

The value is a comma or whitespace separated list of allowable regex's to be
checked against the query param before running the JMX query.

This can allow the effective disable of set or generic query while preserving
get to a finite namespace and invoke to just garbage collection. (Per example
in docs)

Patch preview for the basic concept (disclaimer: untested but up for ideas in
renaming the param names or general approach)
https://github.com/apache/tomcat/compare/main...funkman:jmx_lockdown?expand=1

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 66125] JMProxy - enhance security restrictions

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66125

--- Comment #3 from Mark Thomas <ma...@apache.org> ---
If we want to support provision of metrics to unprivileged or minimally
privileged users then I think we should consider a mechanism that doesn't
involve those users providing the JMX query that gets executed.

For example, a new status servlet could be implemented that provides system
admin selected metrics in a single page - possibly in JSON format. JMX is
likely to be the underlying mechanism used to populate the results and a set of
JMX queries could be used to configure it but all end users would be able to do
is request the page.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 66125] JMProxy - enhance security restrictions

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66125

--- Comment #2 from Tim Funk <fu...@apache.org> ---
100% agreed. I definitely need to add more to the docs to call this out.

For example - in manager-howto.xml - one tweak was the say WARNING instead of
NOTE.

I was hoping to hit the use case of people using JMXProxy for monitoring and
this is a flexible way to limit usage to the "get' operations as well as limit
the scope for what get can see. 

I wasn't sure if this was an OK approach to limit usage as compared to other
possibilities. 

For example: another approach is to moving "op" query string to a path. In
which case: Its easier to add different roles in each of those paths. (But this
approach would have backwards compatibility challenges)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 66125] JMProxy - enhance security restrictions

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66125

--- Comment #1 from Remy Maucherat <re...@apache.org> ---
This enhancement is risky since if there's a problem somehow it will be an
immediate RCE CVE (once people start assuming they can safely expose JMX to the
world).

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 66125] JMProxy - enhance security restrictions

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66125

--- Comment #4 from Tim Funk <fu...@apache.org> ---
True - if that is the case - there is this: /manager/status?XML=true which is
xml, not JSON. 

I'd wonder what additional metrics users were interested that are missing. (As
well as if its worth it to optionally exclude processes currently being
requested)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org