Luego, también por la misma charla, me puse a mirar también el por qué del SecurityManager y el fichero java.policy. Lo que encontré es algo que me llamó bastante la atención.
Aunque todavía no estoy seguro de ello y quiero hacer unos experimentos, el "problema" de seguridad con rmi que obliga al uso e SecurityManager y java.policy es el siguiente:
Cuando un objeto remoto recibe como parámetro un objeto Serializable, se hace una copia del objeto que tiene el cliente en el servidor.
Si un cliente malicioso hace un objeto con código malicioso y lo pasa como parámetro en un método remoto, se está haciendo copia de ese objeto con código malicioso en el servidor. Es posible que el servidor llame a un método inocente de este objeto (por ejemplo, un getNombre()) y en ese método se ejecute el código malicioso.
Esto se evita instalando en el servidor el SecurityManager y el java.policy. En el fichero java.policy, aunque en casi todos los ejemplos se deja con todos los permisos para todo el mundo, se pueden restringir los permisos para cada clase en concreto, en función de que venga o no firmada, se le puede dar permiso o no para abrir y conectarse a sockets, en determiados puertos, para acceso de lectura sólo a determinados directorios del disco, etc, etc.
En el tutorial de java de sun también aconseja el SecurityManager y java.policy en los objetos devueltos por un método remoto y en las excepciones lanzadas por el mismo. No entiendo porqué en el servidor, imagino que se refiere a hacerlo en el cliente, por si el servidor es algo malo y pretende recopilar información "oculta" del cliente que se le conecta.
Sigo en ello y quiero hacer experimentos.
- Probar a arrancar el rmiregistry desde java.
- Hacer un código malicioso en el cliente y ver que efectivamente puede hacer o no lo que le de la gana en función del java.policy.
No hay comentarios:
Publicar un comentario