RE: [Openjmx-devel] RMI adaptor and remote notifications

[Bordet, S. <Sim...@co...>]

Hi,

> >> > If you serialize the filter it is uploaded to the agent, yes.
> >>
> >> My scenario is with the agent running in some server and the client
> >> (Let's say a swing app) writes the filter above and adds a=20
> listener.
> >> Then the listener will be serialized and sent to the agent.=20
> >
> >Of course no !
> >If the listener is run in the server, how can the swing app=20
> be notified
> >of events ?
> >The listener is always remote (from server point of view),=20
> and runs in
> >the client.
> Then you have a MBeanServer on the client side where you set=20
> a listener=20
> listening for events where? on the local MBeans or the RemoteMBeans?
> In the later case the events are produced on the server and=20
> the question is=20
> whether to filter them on the server or on the client
> Am I clear?

No.

On Client you have client application and the RMI connector.
On Server you have RMI adaptor and MBeanServer, with your MBeans.
One of your MBean emit events. MBeanServer dispatches events to =
listeners.
From client you register a remote listener. This listener is "remote" =
for the server. The listener is notified on the client, in the sense =
that handleNotification is run on the client JVM. The client becomes the =
RMI server and the server the RMI client.

Now question is: I want to filter events.
I can do this:
1) on client
2) on server
Option 1 means also filters are remote objects that are called from the =
server.
Option 2 means filters are serialized to the server and run there (with =
security problems we saw).

> Doesn't this problem extend to the MLet service. It is=20
> actually downloading=20
> jars and executing foreign code. My vision is that this=20
> ALWAYS call for a=20
> SecurityManager. Or maybe MLet code should be run in a sandbox

"Sandbox" no.
Yes, using MLets you can download jars and install nasty MBeans. This =
definitely calls for a SecurityManager. There are some trick to be =
solved (for example how to update the policy file) though.

> Again, to create MBeans remotely you need to have the class=20
> definition on the=20
> server either beforehand (Then it can be considerd trusted)=20
> or later via MLet=20
> in which case there should be a protection. Of course you can=20
> assume that if=20
> somebody can create MLets in the server then the access is=20
> controlled and=20
> trusted

Well, in general you cannot.
While HTTP adaptor has basic authentication, RMI adaptor has not. So =
every one can install it and access the MBeanServer (for now).

The point is that with adaptors you need a security manager.

However, I will wait to implement this level of security:
1) it will add some complexity to the code (but this does not worry me)
2) it will add *a lot* of complexity for use of adaptors: login, =
credentials, permissions. And all dynamic. The JMX spec does not address =
security issues, these must be discussed here. For example there should =
be a super user that allows to add new management users (that then may =
login to a http adaptor). So, many security levels... it must be well =
thought.

> >I just wanted here to know the opinion on filters, but the security
> >issue must be faced.
> >Fortunately I know something about it :)
> Good ;-)
> Perhaps you should take a closer look to the Http/SSL=20
> Adapters, there may be=20
> risks there too.

As I told, I would wait to armor our JMX Agent with a tight shield.

Simon