Ruby sandboxing vs. Integración de un lenguaje de script

Question

Actualmente estoy trabajando en un motor de juego basado en texto en Ruby, con la aplicación separada en código Ruby en/lib y datos YAML en/data, que se carga cuando el juego lo necesita . Quiero permitir que los archivos de datos contengan scripts básicos, principalmente en un modelo de evento/observador. Sin embargo, también quiero que los usuarios puedan generar y compartir escenarios personalizados sin tener que preocuparse por códigos maliciosos incrustados en el script.

Adición: Mi plan original era tener contenido creado por el usuario separa en dos tipos, "módulos" que eran sólo de datos (y por tanto segura) y plugins que añade funcionalidad adicional (pero obviamente no eran seguros). Para hacer una analogía con los juegos de mesa, los módulos serían como escenarios de aventuras publicadas y contenido, y los complementos serían libros de reglas que contienen reglas y sistemas adicionales.

Script de ejemplo (sintaxis, por supuesto, sujeta a cambios basados ​​en la solución):

--- 
Location: 
    observers: 
    on_door_open: | 
     monster = spawn_monster(:goblin); 
     monster.add_item(random_item()); 
     monster.hostile = true; 

Desde un punto de vista de la seguridad, sería ideal si scripting era estrictamente opt-in, probablemente a través de un mixin incluido con un poco DSL, por ejemplo:

class Frog 
    include Scriptable 

    def jump; ... ; end # this can be called from a script 
    allow_scripting :jump 

    def ribbit; ... ; end # this cannot be called from a script 
end 

he mirado en tres cuatro opciones, pero no estoy seguro de cuál es el mejor enfoque a adoptar:

1. Usa las secuencias de comandos de Ruby, pero en una caja de arena de algún tipo.

   Pros: Muy familiarizado con Ruby, no hay necesidad de código "pegamento" o problemas de integración de objetos entre idiomas.

   Contras: No muy familiarizados con los problemas de seguridad o sandboxing, no se han encontrado soluciones listas para usar que parezcan encajar.

2. Implemento Incruste otro lenguaje de scripting, p. Lua.

   Pros: Ruby y Lua están basados ​​en C, por lo que las fijaciones deben ser razonablemente simples. Lua es un lenguaje razonablemente popular, por lo que me ayudaré si tengo problemas después. Seguro, ya que cualquier funcionalidad que no vincule específicamente no estará disponible desde los scripts.

   Contras: Los enlaces existentes de Ruby-Lua parecen ser de una sola dirección, viejos y mal mantenidos, o ambos. Parece un poco dudoso para incrustar un lenguaje de scripting dentro de otro lenguaje de scripting.

3. Implemente un lenguaje de scripting personalizado con el intérprete Ruby. He estado experimentando con Treetop, y no debería ser demasiado difícil hacer una gramática simple que sea suficiente para los scripts.

   Pros: No es necesario incrustar otro idioma. Solo la funcionalidad que he implementado específicamente estará disponible para los scripts.

   Contras: Overkill. Síndrome "No construido aquí". Probablemente horrible nido de errores esperando a suceder.

4. Implemente los archivos de datos completamente en Ruby, usando un lenguaje específico de dominio.

   Pros: Simple y fácil.

   Contras: Ningún dato creado por el usuario es confiable.

También estoy abierto a otras sugerencias no en esa lista en las que no haya pensado. ¿Cuál es la mejor solución para implementar scripts de manera segura incrustados en los archivos de datos?

Editar 2011 年 12 月 23 日: Se agregó cuarta opción con DSL, se agregó "adición" en la parte superior con pensamientos/contexto adicionales.

Answer 1

Puede considerar usar Shikashi gem, que le permite crear entornos limitados y definir una lista blanca de llamadas a métodos permitidos en objetos individuales.

Answer 2

Considere usar jRuby en lugar de Ruby. Java se implementó originalmente para admitir código móvil (en los días de set-top) y tiene un bien probado security model/implementation que podría, sospecho, envolver suficiente jRuby para evitar que los scripts/clases de usuario causen estragos en el resto del sistema de juego. . jRuby también admite embedding, lo que puede ayudar a separar el núcleo del juego de las aplicaciones de usuario, aunque no sé cuán robusto es en este momento.

Y, por supuesto, jRuby es Ruby!