Mark,
On 6/13/22 13:19, Mark Thomas wrote:
On 13/06/2022 17:32, Christopher Schultz 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.
Does anyone think this is a good idea?
I for one use jmxproxy at $work for both monitoring /and/
administrative tasks such as restarting applications, listing users,
and initiating garbage collection (in very rare cases). For these
full-write purposes, I could continue to use the (full) jmxproxy role,
but for the monitoring-only ones, it would be nice to lock things down
to the absolute minimum.
Given the widespread use of JMX for monitoring combined with the very
minimal security model provided with JMX, I think there is merit in
trying to improve the situation.
My concern with a simple read-only approach is that there are lots of
attributes exposed via JMX that are considered security sensitive (AJP
secrets, TLS key file passwords etc). With the current model we can't
easily limit access to specific beans and attributes.
My assumption is that most monitoring tools only need a few attributes.
Is there something we can do with the URI to move the bean name,
attribute name, etc into the URI so we can use security constraints to
limit access?
So like a more REST-style interface where the ACL ends up being just
"simple" role-based access using the <security-constraint> framework
already supported by Tomcat?
I agree I'd really like to avoid creating a new type of authorization
system, so this seems like a good path to go down.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
