Esiste un sottoinsieme "sicuro" di Python da utilizzare come linguaggio di scripting incorporato?

Question

Nelle molte applicazioni Python che ho creato, spesso creo moduli semplici contenenti nient'altro che costanti da utilizzare come file di configurazione. Inoltre, poiché il file di configurazione è in realtà un file di codice Python, posso aggiungere una logica semplice per modificare le variabili a seconda del livello di debug, ecc.

Mentre questo funziona perfettamente per applicazioni interne, sarei cauto nel rilasciare tali applicazioni allo stato brado per paura che qualcuno, accidentalmente o maliziosamente, aggiunga codice distruttivo al file. Lo stesso vale per l'utilizzo di Python come linguaggio di scripting incorporato.

Esiste un sottoinsieme di Python ritenuto "sicuro" per l'incorporamento? Capisco quanto può essere considerato sicuro è piuttosto soggettivo. Tuttavia, Java Applet e Flash hanno entrambi la loro sandbox di sicurezza ben definita. Mi chiedo se esiste una versione di Python con regole simili?

EDIT: Sto chiedendo non tanto a causa di un approccio file di configurazione, ma perché sono interessati ad implementare alcuni meccanismi di script/plugin in un app più recente e non voglio un plugin o script per essere in grado di eliminare i file. Ciò va oltre lo scopo di ciò che l'applicazione dovrebbe essere in grado di fare.

Answer 1

Qui ci sono un paio di link per dare un'idea su ciò che si sta di fronte:

• How can I run an untrusted Python script safely (i.e. Sandbox)
• Capabilities for Python? da Guido stesso

C'è anche un morto google code project a http://code.google.com/p/sandbox-python/

Answer 2

Il progetto pypy offre funzionalità di sandboxing, vedere http://doc.pypy.org/en/latest/sandbox.html.

Answer 3

No, non esiste alcun sottoinsieme pronto per la produzione di Python che sia "sicuro". Python ha avuto alcuni moduli sandbox che sono stati deprecati a causa di carenze.

La soluzione migliore è creare il proprio parser o isolare il processo Python con i ganci syscall e un account bloccato.

Alcune persone potrebbero indicarti PyPy, ma è lento e incompiuto.

Answer 4

AFAIK, alcuni tentativi sono stati effettuati nella libreria Python standard, ma non hanno avuto esito positivo. Vedi Restricted Execution per i dettagli.

Warning

In Python 2.3 Questi moduli sono stati disabilitata a causa di vari non buchi sicurezza note e facilmente fissabili. I moduli sono ancora documentati qui per la guida nella lettura del vecchio codice che utilizza i moduli rexec e Bastion.

Answer 5

Sarei cauto nel rilasciare tali applicazioni allo stato brado per timore di qualcuno accidentalmente, o maliziosamente, aggiungendo il codice distruttivo al file.

Il codice nativo "in the wild" è ugualmente vulnerabile a questo attacco; che è in codice macchina è solo un dosso di velocità, e nessuna sicurezza.

Se sei estremamente paranoico e vuoi un speedbump più elevato, puoi fare in modo che l'app nativa che ospita l'istanza di script controlli un hash del contenuto. Quindi i cambiamenti accidenziali sono impossibili; solo le modifiche intenzionali andrebbero a disturbare l'aggiornamento del checksum. Potresti andare oltre e controllare che fossero firmati anche con una chiave pubblica; quindi solo l'hacking della tua app nativa potrebbe consentire l'inserimento di nuovi script.

Ma il sandboxing? Non ti preoccupare!

Answer 6

Si potrebbe provare IronPython su Silverlight/Moonlight, come sembra fare lo these guys in modo impressionante. Ci sono molte ottime informazioni su questi tipi di applicazioni IronPython dagli sviluppatori di Resolver One here.

Answer 7

Non so davvero esattamente quali sono le funzionalità di sicurezza ottenute all'interno della Java Virtual Machine o dei runtime .NET, ma è consigliabile considerare se l'esecuzione del codice Python con Jython o IronPython potrebbe consentire di ottenere maggiore sicurezza .

Answer 8

Per qualche discussione sui problemi già incontrati con il modulo rexec:

• http://mail.python.org/pipermail/python-dev/2002-December/031160.html
• http://mail.python.org/pipermail/python-dev/2003-January/031848.html

Questi provenivano da Restricted Execution HOWTO.

Answer 9

È un po 'difficile capire cosa stai cercando di fare, non abbastanza dettagli.

Stai ospitando l'app nativa e consentendo agli utenti di scrivere plug-in? Prendi in considerazione l'utilizzo di una soluzione a livello di sistema operativo eseguendo l'applicazione Python come processo di runtime separato all'interno di un jail/chroot/simile e comunicando tramite socket.

Ti aspetti che i tuoi clienti possano ospitare l'app nativa e lasciare che le "parti non fidate" scrivano plug-in? C'è una ragione per cui la soluzione sopra non funzionerà? (Ad esempio, il cliente desidera implementare su sistemi operativi bizzarri senza tali opzioni ...)

Ti aspetti che le stesse persone ospiteranno l'app nativa e lo "script non attendibile" e vorranno proteggerli da loro stessi? Nel senso di proteggerli dalla scrittura di "os.remove" e facendogli fare ciò che hanno scritto? Puoi spiegare perché?

Si noti che il sandboxing da solo non è spesso sufficiente senza vincoli più stretti (cicli massimi della CPU, memoria massima, problemi di proprietà della memoria ...)? Che tipo di malizia vuoi fermare? Si noti che anche qui i SO hanno capacità meravigliose (priorità, processi di uccisione, ulimits) che non tutti gli ambienti di sandboxing si replicano - e sono certamente meno testati per la sicurezza rispetto alle cose nei sistemi operativi. (Mi fiderei che Linux non abbia ultrits irrinunciabili prima che mi fiderei di Python per non consentire a un coder malintenzionato di occupare quantità illimitate di memoria, semplicemente perché Linux è stato attaccato di più.)

Answer 10

tinypy (tinypy.org) è stato creato come un piccolo sottoinsieme Python integrato nello stile di Lua. E come lua ha un modo per creare una sandbox, ritengo che la tinypy potrebbe essere hackerata sulla stessa falsariga.Dal momento che la base di codice di tinypy è così piccola, è piuttosto facile imparare e capire come modificare le cose in base alle proprie esigenze.

Answer 11

Il PyMite VM si adatta alla fattura se tutto ciò che dovete fare è impostare semplici variabili, cicli, condizionali e funzioni. PyMite è piccolo, scritto in C, utilizza un pool di memoria statica e può essere incorporato. Ha un insieme estremamente limitato di funzioni integrate che è facile da configurare. Allo stesso modo, le uniche librerie standard sono le implementazioni parziali di stringhe, dict, list e sys. PyMite VM fa parte del progetto python-on-a-chip, quindi è stato progettato per funzionare su microcontrollori, ma può essere eseguito su sistemi desktop in stile posix. Il rovescio della medaglia è che PyMite non è così de-bugged come le altre implementazioni Python.

Answer 12

Questo suona come quello che vuoi: Reviving Python restricted mode.

L'interprete Python dispone di una modalità "riservata", abilitata modificando la variabile magica __builtins__. L'articolo Paving the Way to Securing the Python Interpreter spiega il trucco in modo più dettagliato. Si noti che per funzionare completamente, ha bisogno di una patch per l'intrepreter Python; Non so se è già stato applicato.

Per un proof-of-concept Python puro, vedere il suo post precedente A Challenge To Break Python Security.