Sandbox para ejecutar código de Python posiblemente hostil

Digamos que hay un servidor en Internet al que se puede enviar un fragmento de código para su evaluación. En algún momento, el servidor toma todo el código que se ha enviado, y comienza a ejecutarlo y evaluarlo. Sin embargo, en algún momento definitivamente se encontrará con “os.system (‘rm -rf *’)” enviado por algún progtwigdor malvado. Además de “rm -rf”, se puede esperar que la gente intente usar el servidor para enviar correo no deseado o dos personas, o se entretenga con el tipo de cosas “While True: pass”.

¿Hay alguna manera de cooperar con un código tan poco amigable / no confiable? En particular estoy interesado en una solución para python. Sin embargo, si tiene información para cualquier otro idioma, por favor comparta.

Puede verificar pysandbox que hace exactamente eso, aunque la ruta de la máquina virtual es probablemente más segura si se lo puede permitir.

Si no es específico de la implementación de CPython, debería considerar consultar PyPy [wiki] para estos fines: este dialecto de Python permite el uso de código de fondo transparente.

De lo contrario, puede proporcionar __builtin__ y __builtins__ en los argumentos globales / locales correspondientes a exec o eval .

Además, puede proporcionar un objeto similar a un diccionario en lugar de un diccionario real y rastrear lo que hace un código no confiable con su espacio de nombres.

Además, puede realmente rastrear ese código (emitir sys.settrace() dentro de un entorno restringido antes de que se ejecute cualquier otro código) para que pueda interrumpir la ejecución si algo va mal.

Si ninguna de las soluciones es aceptable, use el sandboxing a nivel de sistema operativo como chroot , unionfs y el módulo estándar de multiprocess python para generar un trabajador de código en un proceso seguro separado.

Es imposible proporcionar una solución absoluta para esto porque la definición de “malo” es bastante difícil de definir.

¿Abrir y escribir en un archivo es malo o bueno? ¿Qué pasa si ese archivo es / dev / ram?

Puede perfilar firmas de comportamiento, o puede intentar bloquear cualquier cosa que pueda ser mala, pero nunca ganará. Javascript es un buen ejemplo de esto, la gente ejecuta código de javascript arbitrario todo el tiempo en sus computadoras: se supone que está en un espacio aislado, pero hay todo tipo de problemas de seguridad y condiciones de borde que surgen.

No estoy diciendo que no lo intentes, aprenderás mucho del proceso.

Muchas compañías han gastado millones (Intel acaba de gastar miles de millones en McAffee) tratando de entender cómo detectar “códigos erróneos”, y cada día las máquinas que ejecutan el antivirus McAffe se infectan con virus. El código Python no es menos peligroso que C. Puedes ejecutar llamadas al sistema, enlazar con bibliotecas C, etc.

Consideraría seriamente la posibilidad de virtualizar el entorno para ejecutar estas cosas, de modo que las vulnerabilidades en cualquier mecanismo que implementen se puedan instalar en el servidor de seguridad una vez más mediante la configuración de la máquina virtual.

La cantidad de usuarios y el tipo de código que espera probar / ejecutar tendría una influencia considerable en las opciones por cierto. Si no se espera que se vinculen a archivos o bases de datos, o ejecuten tareas intensivas en computación, y usted tenga una presión muy baja, podría estar casi bien simplemente impidiendo por completo el acceso a los archivos e imponiendo un límite de tiempo en el proceso antes de que se elimine. La presentación marcada como demasiado costosa o maliciosa.

Si el código que se supone que debe probar puede ser una extensión o página de Django arbitraria, es probable que tenga mucho trabajo.

Puedes probar algunos sanbox generics como Sydbox o el sandbox de Gentoo . No son específicos de Python.

Ambos se pueden configurar para restringir la lectura / escritura en algunos directorios. Sydbox puede incluso cajas de arena.

Creo que una solución como esta va a ser muy difícil y me recuerda a una conferencia a la que asistí sobre los beneficios de la progtwigción en un entorno virtual. Si lo haces virtualmente es genial si lo fastidian. No se resolverá en un momento Verdadero: pase pero rm -rf / no importa.

A menos que me equivoque (y muy bien podría estarlo), esta es una de las razones detrás de la forma en que Google cambió Python para App Engine. Ejecuta el código Python en su servidor, pero han eliminado la capacidad de escribir en archivos. Todos los datos se guardan en la base de datos “nosql”.

No es una respuesta directa a su pregunta, sino un ejemplo de cómo se ha tratado este problema en algunas circunstancias.