¿Existe un subconjunto “seguro” de Python para usarlo como lenguaje de scripts incrustado?

En las muchas aplicaciones de Python que he creado, a menudo creo módulos simples que no contienen más que constantes para usar como archivos de configuración. Además, dado que el archivo de configuración es en realidad un archivo de código Python, puedo agregar una lógica simple para cambiar las variables en función de un nivel de depuración, etc.

Si bien esto funciona muy bien para aplicaciones internas, desconfiaría de liberar tales aplicaciones en la naturaleza por temor a que alguien, de manera accidental o maliciosa, agregue código destructivo al archivo. Lo mismo sucedería con el uso de Python como un lenguaje de scripting incorporado.

¿Existe un subconjunto de Python que se considere “seguro” para la inserción? Me doy cuenta de lo seguro que puede considerarse que es bastante subjetivo. Sin embargo, Java Applets y Flash tienen su caja de seguridad bien definida. Me pregunto si hay una versión de Python que tenga reglas similares.

EDITAR: No pido mucho por el enfoque del archivo de configuración, sino porque estoy interesado en implementar algunos mecanismos de secuencias de comandos / complementos en una aplicación más nueva y no quiero que un complemento o secuencia de comandos pueda, digamos, eliminar archivos. Eso va más allá del scope de lo que la aplicación debería poder hacer.

Aquí hay un par de enlaces para darle una idea de a qué se enfrenta:

  • ¿Cómo puedo ejecutar un script de Python no confiable de manera segura (es decir, Sandbox)
  • Capacidades para Python? por Guido mismo

También hay un proyecto de código de Google muerto en http://code.google.com/p/sandbox-python/

No, no hay ningún subconjunto de Python listo para la producción que sea “seguro”. Python ha tenido unos pocos módulos de caja de arena que fueron desaprobados debido a deficiencias.

Su mejor apuesta es crear su propio analizador o aislar el proceso de Python con ganchos de syscall y una cuenta encarcelada.

Algunas personas pueden dirigirte a PyPy, pero es lento e inacabado.

La máquina virtual de PyMite se ajusta a la cuenta si todo lo que necesita hacer es configurar variables, bucles, condicionales y funciones simples. PyMite es pequeño, escrito en C, utiliza un grupo de memoria estática y se puede incrustar. Tiene un conjunto extremadamente limitado de funciones integradas que es fácil de configurar. De manera similar, las únicas bibliotecas estándar son implementaciones parciales de string, dict, list y sys. El PyMite VM es parte del proyecto python-on-a-chip, por lo que fue diseñado para ejecutarse en microcontroladores, pero puede ejecutarse en sistemas de escritorio estilo posix. El inconveniente es que PyMite no está tan ampliamente depurado como otras implementaciones de Python.

El proyecto pypy ofrece funciones de espacio aislado, consulte http://doc.pypy.org/en/latest/sandbox.html .

tinypy ( tinypy.org ) se creó para ser un pequeño subconjunto de Python integrado en el estilo de Lua. Y como lua tiene una manera de crear una caja de arena, estimo que Tinypy podría ser hackeado en la misma vena. Dado que el código base de Tinypy es tan pequeño, es bastante fácil de aprender y descubrir cómo cambiar las cosas para que se ajusten a sus necesidades.

AFAIK, se hicieron algunos bashs en la biblioteca estándar de python, pero no tuvieron éxito. Consulte Ejecución restringida para más detalles.

Advertencia

En Python 2.3, estos módulos se han deshabilitado debido a varios agujeros de seguridad conocidos y no fáciles de reparar. Los módulos aún están documentados aquí para ayudar a leer el código antiguo que usa los módulos rexec y Bastion.

No me atrevo a lanzar tales aplicaciones a la naturaleza por temor a que alguien, ya sea accidental o maliciosamente, agregue un código destructivo al archivo.

Su código nativo que está “en la naturaleza” es igualmente vulnerable a este ataque; Que esté en el código de la máquina es solo un golpe de velocidad, y no hay seguridad.

Si es extremadamente paranoico y desea un Speedbump más alto, podría hacer que su aplicación nativa que aloja la instancia de script compruebe un hash del contenido. Entonces los cambios accidentales son imposibles; solo los cambios deliberados se tomarán la molestia de actualizar la sum de comprobación. Podría ir más allá y verificar que también se hayan firmado con una clave pública; entonces solo hackear su aplicación nativa podría dejar nuevos scripts.

¿Pero el sandboxing? No te preocupes por eso!

Puede probar IronPython en Silverlight / Moonlight, ya que estos chicos parecen estar impresionados. Hay una gran cantidad de gran información sobre estos tipos de aplicaciones IronPython de los desarrolladores de Resolver One aquí .

Realmente no sé exactamente qué capacidades de seguridad obtienes dentro de los tiempos de ejecución de la Máquina Virtual Java o .NET, pero es posible que desees considerar si ejecutar tu código python con Jython o IronPython podría permitirte obtener seguridad adicional.

Es un poco difícil de entender lo que estás tratando de hacer, no hay suficientes detalles.

¿Está hospedando la aplicación nativa y permitiendo que los usuarios escriban complementos? Considere usar una solución a nivel de sistema operativo ejecutando la aplicación Python como un proceso de tiempo de ejecución separado dentro de una cárcel / chroot / similar, y comunicándose a través de sockets.

¿Espera que sus clientes alojen la aplicación nativa y permitan que los “terceros no confiables” escriban complementos? ¿Hay alguna razón por la que la solución anterior no funcione? (Por ejemplo, el cliente desea implementar en sistemas operativos extraños sin tales opciones …)

¿Espera que las mismas personas alojen la aplicación nativa y el “script no confiable” y quieran protegerlos de ellos mismos? ¿En el sentido de protegerlos de escribir “os.remove” y hacer que haga lo que escribieron? ¿Puedes explicar porque?

¿Tenga en cuenta que el sandboxing solo no suele ser suficiente sin restricciones más estrictas (ciclos de CPU máximos, memoria máxima, problemas de propiedad de la memoria …)? ¿Qué tipo de maldad quieres detener? Tenga en cuenta que aquí, también, los sistemas operativos tienen capacidades maravillosas (prioridades, procesos de eliminación, ulimits) que no todos los entornos de espacio aislado se replican, y ciertamente son menos probados en seguridad que los sistemas operativos. (Confiaría en que Linux no tenga ulimits rompibles antes de confiar en que PyPy no permita que un progtwigdor malicioso consum cantidades ilimitadas de memoria, simplemente porque Linux ha sido atacado en la naturaleza más).

Para una discusión sobre los problemas previamente reunidos con el módulo rexec :

Estos vinieron de la Ejecución restringida HOWTO .

Esto suena como lo que quieres: Revivir el modo restringido de Python .

El intérprete de Python tiene un modo “restringido” incorporado, habilitado al cambiar la variable mágica __builtins__ . El artículo Allanando el camino para asegurar el intérprete de Python explica el truco con más detalle. Tenga en cuenta que para funcionar completamente, necesita un parche para el intrepreter de Python; No sé si ya se ha aplicado.

Para una prueba de concepto pura de Python, consulte su publicación anterior A Challenge to Break Python Security .