Foro - Perl en Español

Hola, ¿conocéis alguna forma de hacer no accesible los ficheros críticos de Linux que pueden invocarse desde Perl?

Por ejemplo, si tienes una app que puedes subir ficheros Perl o plantillas que puedan tener embebido código Perl, ¿qué habría que hacer para que las sentencias del tipo system(“ls”) o system (vi /etc/passwd) no se puedan ejecutar?

Un saludo, muchas gracias.

Se podrían ajustar los permisos de los directorios y ficheros, para que no puedan ser accedidos por el usuario que ejecuta el programa (normalmente, el usuario que ejecuta el servidor web).

Otra opción es la usar SuExec, en Apache, que movería la propiedad de la ejecución del programa, desde el usuario que ejecuta el servidor web, hasta el usuario que es dueño del programa, por lo que se reducen bastante los problemas de seguridad.

Otra opción: modificar el $PATH que el servidor web es capaz de ver, reduciendo los directorios de ejecutables que no queremos que use, pero puede afectar el uso de otros programas que sí necesitan esos ejecutables.

Hay posibilidades de "enjaular" el servidor web, pero a veces, eso da problemas.

En Apache2 puedes instalar el módulo mod_security, que trae muchas cosas relacionadas con la seguridad. El problema es que si lo enjaulas con la opción SecChrootDir, el usuario legítimo no podrá acceder a todos los módulos y librerías, ya que estarán residiendo fuera de la jaula. La solución sería tener una copia de la distribución Perl dentro de la jaula.

La solución más moderna pasa por instalar a los usuarios en máquinas virtuales. Así, si tocan algo, solo será en su propio servidor, y no afectará al resto de usuarios/máquinas.

Seguro que hay más opciones...

Muchas gracias.

Hola de nuevo, he encontrado un módulo que se llama "use Safe;". Estoy revisando los comandos a ver si puedo invocar a este comando en cada lectura de línea de mi código Perl para comprobar que no hay ninguna línea peligrosa. ¿Habéis trabajado con este módulo? No sé el alcance que pueda tener y si es suficiente.

Mi problema en concreto es que con esto se solucionaría todas las invocaciones al sistema a través de system(), pero se puede hacer todo tipo de comandos con Perl, con lo que si este módulo funciona "use Safe" en principio se solucionarían las invocaciones a Linux pero no a Perl.

¿Conocéis algo de esto?

Un saludo.

En este hilo se comentan el Jailkit y la función chroot() desde el propio perl.

Aún así... aún no lo veo claro...

¿Te refieres a limitar la ejecución desde el intérprete de perl desde la línea de comandos o desde la ejecución de un CGI Perl?

Hola, me refiero a controlarlos desde la propia plantilla. En nuestra empresa trabajamos con código Perl embebido en el propio HTML, de la forma:

Todo lo que esté delimitado por las etiquetas g:eval lo parseamos y lo llevamos al intérprete de Perl. La ejecución de los html con el código embebido se hace a través de CGI y lo que estamos intentando hacer es poder evitar las llamadas a system(), mkdir(), unlink(), etc. Todas las sentencias que pongan en peligro la integridad física de los ficheros y de la propia seguridad.

Sigo probando el tema, he avanzado un poco con Safe y recuperando la salida con $@, pero aun no sé si esto será suficiente. Cualquier avance os comento

Muchas gracias.

Permitirle al usuario que modifique una plantilla y que pueda escribir cualquier tipo de código, es muy peligroso.

Lo ideal es que todas las plantillas sean locales en el propio sistema. Y que solo puedan ser modificadas por el equipo de desarrollo.

La solución es muy complicada, porque se pueden ejecutar y tener accesos a ficheros, de muchas maneras distintas.

Ni siquiera puedes poner un filtro para quedarte con instrucciones "no peligrosas": un simple open() puede lanzar un proceso.

Mi consejo es que uséis un método distinto: el usuario no puede ni debe poder ejecutar nada, enviándolo desde el lado del cliente hacia el servidor.

Un método muy bueno, en los CGI, es activar el modo taint, usando la opción "-T" en la primera línea del cgi, en la del shebang. Será capaz de identificar las zonas peligrosas del programa, y a tomar medidas con respecto a cualquier cosa que el usuario envíe.

Cosa distinta es que las plantillas estén todas en el lado del servidor. Entonces los problema de seguridad están en las personas que son capaces de manipular esas plantillas (en principio, se suponen que son desarrolladores y que se puede confiar en ellos, ¿no?)

Leotrillo escribiste:Hola, ¿conocéis alguna forma de hacer no accesible los ficheros críticos de Linux que pueden invocarse desde Perl?

En Linux a nivel de sistema operativo puedes limitar las acciones que puede ejecutar cada programa utilizando SELinux o AppArmor. Es un poco laborioso pero a la larga es lo unico que te da ciertas garantias de que un usuario malicioso no se salte tus normas.