Soy el desarrollador del motor Robocode. Queremos que Robocode sea multilingüe y Scala parece ser una buena combinación. Tenemos el complemento Scala prototype here.Seguridad de scala runtime
El problema: Dado que los usuarios son los programadores creativos, pueden tratar de ganar la batalla maneras diferentes. Además, los robots se descargan de la base de datos en línea , donde cualquiera puede subir uno. Así que la brecha en la seguridad puede conducir a la seguridad agujero en la computadora de los usuarios. Los robots escritos en Java se están ejecutando en sandbox restringido. Casi todo está prohibido [red, GUI, disco (limitado), hilos (limitados), cargadores de clases y reflejo]. La caja de arena es similar a la aplicación de navegador. Utilizamos SecurityManager, a medida ClassLoader por robot, etc ...
Hay dos maneras de cómo alojar Scala en tiempo de ejecución: Robocode
1) de carga junto con robot dentro de la caja de arena. Bastante seguro para nosotros, solución preferida. Pero dañará las capacidades de tiempo de ejecución de Scala porque el tiempo de ejecución usa la reflexión. ¿Tal vez genera clases en tiempo de ejecución? Use hilos para hacer una limpieza interna? ¿Acceso a JVM/internos? (No me gustaría limitar las capacidades del lenguaje)
2) utilice el tiempo de ejecución de Scala como código de confianza, fuera de la caja, la seguridad en mismo nivel que JDK. Visibilidad del robot (malicioso) . ¿Son seguras las API de tiempo de ejecución Scala? ¿Tienen métodos de seguridad guardias? ¿Hay algún modo seguro? ¿Hay algún singleton en el tiempo de ejecución de Scala, que podría ser objeto de abuso para comunicarse entre robots? Cualquier concurency/threadpool/mensaje que podría simular hilos? (¿Hay alguna auditoría de seguridad para el tiempo de ejecución de Scala?)
3) Algo intermedio, algunas clases de tiempo de ejecución dentro y algunas fuera. ¿Qué clases/paquetes deben ser visibles para el robot/que son solo una implementación privada? (Esto parece ser la solución futura)
La pregunta: ¿Es posible enumerar y aislar las partes de tiempo de ejecución, que se deben ejecutar en alcance de confianza del resto? ¿Paquetes y clases específicos? ¿O mejor idea?
Estoy buscando una respuesta específica, que dará lugar a una solución segura. Se aceptan pensamientos aleatorios, pero no se otorgan. Hay un debate en curso en scala email group. Sin respuesta específica todavía.
Enlace al hilo sobre reflexión y matrices: http://thread.gmane.org/gmane.comp.lang.scala.internals/2590 –
Varios puntos buenos aquí. Con respecto al objetivo en movimiento, a la derecha, me complace bloquear la versión única de Scala. En cuanto a "¡Ajá! Usaré la reflexión para resolver esto". eso es un acto criminal. No me gustaría que mis usuarios/novatos se quejen en nuestro grupo de soporte sobre el tiempo de ejecución roto que no nos pertenece. No está claro para mí si el tiempo de ejecución al menos ajustará/convertirá la excepción en algo consistente. ¿Tiene al menos AccessController.doPrivileged() para tales acciones? –
Tienes que considerar los objetivos de mercado de Scala. La reflexión es bastante omnipresente en los frameworks web de Java y en los lenguajes dinámicos basados en JVM. Es bastante menor en comparación con la manipulación del código de bytes en tiempo de ejecución, que también es común. También tenga en cuenta que el uso de la reflexión no está necesariamente restringido al tiempo de ejecución o la biblioteca, sino que el compilador simplemente emite llamadas dentro del código de usuario normal. No puedo encontrar una sola instancia de AccessController en la fuente de Scala, así que no creo que sea del todo consciente de tales cosas. –