Python non ha un modello di sicurezza che ti permette di eseguire in sicurezza il codice non fidato all'interno del tuo programma. Persino nei linguaggi che hanno modelli di sicurezza di questo tipo (come Java) ci sono innumerevoli bug che rendono discutibile l'uso di questo modello di sicurezza.
Esistono due approcci ragionevoli a questo problema di sicurezza:
-
usa le funzionalità di sicurezza del sistema operativo, ad es. seccomp / capabilities / namespaces in Linux.
-
non consentono il codice senza limitazioni, ma interpretano invece un linguaggio specifico del dominio o parametrizzano il tuo input con un semplice modello di dati. Per molti domini problematici, la configurazione al posto del codice è un approccio ragionevole. Potrebbe anche essere possibile includere una macchina virtuale sandboxed, ad es. un ambiente JavaScript.
La terza soluzione è probabilmente la più realistica: adattare il modello di sicurezza dell'applicazione alla realtà in cui verrà eseguito il codice che non hai scritto. Per esempio. se gli utenti eseguono il tuo software da soli, tutti i plug-in che scrivono sono il loro problema. Questo va bene, purché tu possa documentare questa possibilità.
Si noti che il solo fatto di non consentire importazioni non è utile se si forniscono oggetti definiti dall'utente al codice non attendibile. Utilizzando il reflection, è spesso possibile accedere a qualsiasi variabile dal modulo in cui è stata definita, incluso un set completo di builtin o altri moduli già importati.