Ruby sandboxing vs. integrazione di un linguaggio di scripting

Question

Attualmente sto lavorando a un motore di gioco basato su testo in Ruby, con l'app separata in codice Ruby in/lib e dati YAML in/data, che viene caricata quando necessario dal gioco . Voglio consentire ai file di dati di contenere script di base, principalmente in un modello di evento/osservatore. Tuttavia, voglio anche che gli utenti siano in grado di generare e condividere scenari personalizzati senza doversi preoccupare del codice dannoso incorporato nello script.

addendum: mio piano originale era quello di avere contenuti creati separato in due tipi, "moduli", che erano soli dati (e quindi sicuro) e plugin che aggiunge funzionalità aggiuntive (ma ovviamente non erano sicuri). Per fare un'analogia con il gioco da tavolo, i moduli sarebbero come scenari e contenuti di avventura pubblicati e i plugin sarebbero libri di regole contenenti regole e sistemi aggiuntivi.

Script di esempio (sintassi ovviamente soggetta a modifiche in base soluzione):

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

Dal punto di vista della sicurezza, sarebbe ideale se scripting era rigorosamente opt-in, probabilmente attraverso un mixin incluso con un po ' DSL, ad esempio:

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 

ho guardato tre quattro opzioni, ma non sono sicuro che è l'approccio migliore per prendere:

1. Utilizzare lo script Ruby, ma in una sandbox di qualche tipo.

   Pro: Molto familiare con Ruby, nessuna necessità di codice "colla" o problemi di integrazione di oggetti tra le lingue.

   Contro: Non molto familiare con problemi di sicurezza o sandboxing, non ho trovato nessuna soluzione pronta per l'uso che sembra adattarsi.

2. Implementare Incorporare un altro linguaggio di scripting, ad es. Lua.

   Pro: Ruby e Lua sono basati su C, quindi i binding dovrebbero essere ragionevolmente semplici. Lua è un linguaggio ragionevolmente popolare, quindi aiuto disponibile se mi imbatto in problemi successivi. Sicuro, dal momento che qualsiasi funzionalità che non associo in modo specifico non sarà disponibile dagli script.

   Contro: Gli attacchi esistenti in Ruby-Lua sembrano essere a senso unico, vecchio e mal gestito, o entrambi. Sembra un acaro dubbia di incorporare un linguaggio di scripting in un altro linguaggio di scripting.

3. Implementare un linguaggio di scripting personalizzato con l'interprete Ruby. Ho sperimentato con Treetop e non dovrebbe essere troppo difficile fare una semplice grammatica che sarebbe sufficiente per gli script.

   Pro: Non è necessario incorporare un'altra lingua. Solo le funzionalità che ho implementato in modo specifico saranno disponibili per gli script.

   Contro: Overkill. Sindrome "non costruita qui". Probabilmente orrendo nido di insetti in attesa di accadere.

4. Implementare i file di dati interamente in Ruby, utilizzando un linguaggio specifico del dominio.

   Pro: Semplice e facile.

   Contro: Nessun dato creato dall'utente è affidabile.

Sono aperto anche ad altri suggerimenti non presenti in quella lista a cui non avrei pensato. Qual è la soluzione migliore per implementare in modo sicuro gli script incorporati nei file di dati?

Edit 2011 年 12 月 23 日: Aggiunta quarta opzione con DSL, ha aggiunto "addendum" in alto con l'aggiunta di pensieri/contesto.

Answer 1

È possibile utilizzare Shikashi gem, che consente di creare sandbox e definire una whitelist di chiamate di metodo consentite su singoli oggetti.

Answer 2

Considerare l'utilizzo di jRuby anziché Ruby. Java è stato originariamente implementato per supportare il codice mobile (nei giorni in cui è stato impostato il set-top) e ha un collaudato codice security model/implementation che potrebbe, sospetto, avvolgere abbastanza jRuby per impedire agli script/classi utente di creare scompiglio con il resto del sistema di gioco . jRuby supporta anche embedding, che può aiutare a separare il nucleo del gioco dalle applicazioni utente, anche se non so quanto sia robusto in questo momento.

E, naturalmente, jRuby è Ruby!