Mark,
On 6/13/22 14:56, Mark Thomas wrote:
On 13/06/2022 19:34, Christopher Schultz wrote:
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?
Yes, something along those sort of lines.
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.
Another option that occurred to me reading the rest of this thread was
some sort of (JSON formatted?) status page that displayed a specified
sub-set of beans and attributes. There would need to be some sort of
config file to select beans and attributes but other than that, security
could be provided by the standard security constraint approach.
If this was a servlet, you could have multiple instances of the Servlet
with different configurations for different users.
Another fairly good idea IMO. It even addresses Tim's (reasonably)
paranoid concerns about exposing JMX at all. This could be implemented
behind the scenes using JMX, but as far as the client is concerned, it
just sees "status" and doesn't care where the values come from.
It has the added benefit of being able to return multiple status bits at
once instead of having to make multiple roundtrips to Tomcat to get the
status of several items separately.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
