SEGURIDAD EN UNIX Y REDES

84CAPÍTULO 5. PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOSun proceso. Especialmente críticas son las funciones que dependen del shell para ejecutar unprograma, como system() o execvp(): en estos casos es muy difícil asegurar que el shell vaa ejecutar la tarea prevista y no otra. Por ejemplo, imaginemos el siguiente código:#include main(){system("ls");}A primera vista, este programa se va a limitar a mostrar un listado del directorio actual; noobstante, si un usuario modifica su $PATH de forma que el directorio ‘.’ ocupe el primerlugar, se ejecutará ./ls en lugar de /bin/ls. Si el programa ./ls fuera una copia del shell, yel código anterior estuviera setuidado por el root, cualquier usuario podría obtener privilegiosde administrador.Quizás alguien puede pensar que el problema se soluciona si se indica la ruta completa(/bin/ls) en lugar de únicamente el nombre del ejecutable; evidentemente, esto arreglaría elfallo anterior, pero seguirían siendo factibles multitud de ataques contra el programa. Desdela modificación del $IFS (como veremos más adelante) hasta la ejecución en entornosrestringidos, existen muchísimas técnicas que hacen muy difícil que un programa con estascaracterísticas pueda ser considerado seguro.• Nunca setuidar shellscripts.Aunque en muchos sistemas Unix la activación del bit setuid en shellscripts no tiene ningúnefecto, muchos otros aún permiten que los usuarios – especialmente el root – creen procesosinterpretados y setuidados. La potencia de los intérpretes de órdenes de Unix hace casi imposiblecontrolar que estos programas no realicen acciones no deseadas, violando la seguridad delsistema, por lo que bajo ningún concepto se ha de utilizar un proceso por lotes para realizaracciones privilegiadas de forma setuidada.• No utilizar creat() para bloquear.Una forma de crear un fichero de bloqueo es invocar a creat() con un modo que no permitala escritura del archivo (habitualmente el 000), de forma que si otro usuario tratara de hacerlo mismo, su llamada a creat() fallaría. Esta aproximación, que a primera vista parececompletamente válida, no lo es tanto si la analizamos con detalle: en cualquier sistema Unix,la protección que proporcionan los permisos de un fichero sólo es aplicable si quien trata deacceder a él no es el root. Si esto es así, es decir, si el UID efectivo del usuario que está accediendoal archivo es 0, los permisos son ignorados completamente y el acceso está permitido;de esta forma, el root puede sobreescribir archivos sin que le importen sus bits rwx, lo queimplica que si uno de los procesos que compiten por el recurso bloqueado está setuidado anombre del administrador, el esquema de bloqueo anterior se viene abajo.Para poder bloquear recursos en un programa setuidado se utiliza la llamada link(), yaque si se intenta crear un enlace a un fichero que ya existe link() falla aunque el proceso quelo invoque sea propiedad del root (y aunque el fichero sobre el que se realice no le pertenezca).Tambiénes posible utilizar la llamada al sistema flock() de algunos Unices, aunque esmenos recomendable por motivos de portabilidad entre clones.• Capturar todas las señales.Un problema que puede comprometer la seguridad del sistema Unix es el volcado de la imagenen memoria de un proceso cuando éste recibe ciertas señales (el clásico core dump). Esto puedeprovocar el volcado de información sensible que el programa estaba leyendo: por ejemplo, enversiones del programa login de algunos Unices antiguos, se podía leer parte de /etc/shadowenviando al proceso la señal sigterm y consultando el fichero de volcado.