unknown
1970-01-01 00:00:00 UTC
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).
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.
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.
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
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.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
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.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
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 ;-)issue must be faced.
Fortunately I know something about it :)
Perhaps you should take a closer look to the Http/SSL=20
Adapters, there may be=20
risks there too.
Simon