Sicurezza di runtime scala

Question

Sono uno sviluppatore del motore Robocode. Vorremmo rendere Robocode multilingue e Scala sembra essere una buona partita. Abbiamo il plugin Scala prototype here.

Il problema: Poiché gli utenti sono programmatori creativi, possono provare a vincere la battaglia modi diversi. Inoltre, i robot vengono scaricati dal database online in cui chiunque può caricarne uno. Quindi la mancanza di sicurezza può portare al buco di sicurezza nel computer degli utenti. I robot scritti in Java sono in esecuzione nella sandbox limitata . Quasi tutto è vietato [rete, interfaccia grafica, disco (limitato), thread (limitato), classloader e riflessione]. La sandbox è simile all'applet del browser. Usiamo SecurityManager, personalizzato ClassLoader per robot, etc ...

Ci sono due modi come ospitare Scala runtime in Robocode:

1) caricarlo insieme ai robot all'interno della sandbox. Piuttosto sicuro per noi, soluzione preferita . Ma danneggerà le abilità di runtime di Scala perché il runtime usa la riflessione. Forse genera classi in fase di runtime? Utilizzare i thread per eseguire una pulizia interna? Accesso a JVM/interni? (Non vorrei limitare le capacità del linguaggio)

2) utilizzare il runtime di Scala come codice attendibile, fuori dagli schemi, sicurezza su allo stesso livello di JDK. Visibilità al robot (dannoso) . Le API di runtime di Scala sono sicure? I metodi hanno le protezioni di sicurezza ? Esiste una modalità sicura? C'è qualche singleton nel runtime di Scala, che potrebbe essere abusato per comunicare tra i robot? Qualsiasi concurrency/threadpool/messaging che potrebbe simulare i thread? (Esiste un controllo di sicurezza per il runtime di Scala?)

3) Qualcosa nel mezzo, alcune classi di runtime dentro e alcune fuori. Quali classi/pacchetti devono essere visibili al robot/che sono solo un'implementazione privata? (Questa sembra essere la soluzione futura)

La domanda: E 'possibile enumerare e isolare le parti del tempo di esecuzione, che deve essere eseguito in portata di fiducia dal resto? Pacchetti e classi specifici? O un'idea migliore?

Sto cercando una risposta specifica, che porterà a una soluzione sicura. Pensieri casuali benvenuti, ma non assegnati. Sono in corso discussioni allo scala email group. Nessuna risposta specifica ancora.

Answer 1

Penso che il n. 1 sia la soluzione migliore e anche questo è un bersaglio mobile. Come riportato nella mailing list, i tipi strutturali usano la riflessione. Non penso che i tipi strutturali siano comuni nella libreria standard, ma non penso che nessuno tenga traccia di dove si trovano.

C'è sempre anche la possibilità che ci siano altre funzionalità che utilizzano il riflesso dietro le quinte. Ad esempio, per un po 'nel ramo 2.8 alcune funzionalità dell'array utilizzavano il reflection. Penso che sia cambiato dopo il benchmarking, ma c'è sempre la possibilità che ci sia qualche problema in cui qualcuno ha detto "Aha! Userò il riflesso per risolvere questo problema".

La libreria standard di Scala è piena di singleton.Molti di questi sono immutabili, ma so che l'oggetto Scheduler nella libreria degli attori potrebbe essere sfruttato per la comunicazione perché è essenzialmente un proxy per un vero programmatore in modo da poter inserire il proprio programma di pianificazione personalizzato su di esso.

In questo momento non penso che Scala richieda l'utilizzo di un programma di caricamento classi personalizzato e che tutte le sue classi siano prodotte in fase di compilazione anziché in fase di runtime, ma di nuovo probabilmente si tratta di un obiettivo mobile. Scala genera molti file di classe e si parla sempre di generarne alcuni in fase di esecuzione quando sono necessari invece che in fase di compilazione.

Quindi, in breve, non penso sia possibile (entro limiti ragionevoli sullo sforzo) enumerare e isolare i pezzi di Scala che possono (e dovrebbero) essere considerati attendibili.

Answer 2

Come hai menzionato altre implementazioni di linguaggio J * che possono tutte fare uso di riflessioni, sarebbe un divieto per tutte quelle lingue finché il riflesso non fa parte del gioco. Immagino che sarebbe il problema di JVM non avere un modo per partizionare l'ambito dell'API di reflection, in modo tale da poter creare una sorta di "sandbox" la parte di codice che potrebbe essere riflessa all'interno.