Tim,
On 6/13/22 12:54, Tim Funk wrote:
I think JMXProxy should be eventually deprecated. It's "too powerful" for
what it can do. At the time of creation - it was a neat idea that was
powerful. But if I had to imagine if we would create such a servlet today,
security alarms would be loudly clanging.
I think a read only option would help lock things down for those who prefer
only reading JMX stats. So in that sense it's an extra layer of support.
But conversely, I also think it's a false sense of security.
Fair enough.
I think the JMXProxyServlet is better than JMX itself for a number of
reasons. Though platform JMX access has improved in the last few
versions, the fact is that Tomcat's ability to provide access to JMX
(through HTTP) is far more flexible and secure than the heavy-handed JMX
capabilities provided by the platform.
I would be strongly against deprecating the JMXProxyServlet for that
reason moving forward.
-chris
On Mon, Jun 13, 2022 at 12:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
All,
I've been thinking about the possibility of making a read-only JMX role
available for the existing manager-jmx capability.
The idea would be that this role would only be able to make "get"
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or
"invoke" operations would be allowed.
The manager-jmx role has quite a bit of power, and is typically used
only for monitoring where being able to modify the server is not
necessary. If manager-jmx is being used "only" for monitoring, then
opening-up the system for potential reconfiguration by the monitoring
user is a potential attack vector.
I don't think the level-of-effort would be significant: simply require
"manager-jmx" for set/invoke operations and require either manager-jmx
or manager-jmx-read-only (or something similar) for get operations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
