¿Cómo Escribir Programas Seguros? - Usar procesos SUID/SGID de forma inteligente

Existen casos, sin embargo, en los que un proceso SUID contribuye a mejorar la seguridad sensiblemente. Por ejemplo, un CGI web suele ejecutarse con los privilegios del propio servidor web (normalmente como "nobody"). No obstante el usuario "nobody" tiene acceso de lectura a los ficheros públicos del servidor, lo que suele incluir el propio "/etc/passwd". Si no estamos usando "shadow" (muchas instalaciones Linux no lo usan) significa que un compromiso en el CGI permite a un atacante obtener una copia del fichero de claves. Si tenemos algún tipo de base de datos para el control de acceso a algunas partes del web, también será accesible por el CGI.

En un contexto así lo ideal sería ejecutar el servidor Web directamente dentro de un "chroot". Si ello es posible, perfecto, pero no siempre es así. Un servidor Web, en instalaciones pequeñas, suele tener acceso "legítimo" a ficheros repartidos por todo el disco, y proteger eso es misión imposible.

¿De qué nos sirve un script SUID aquí?. Un script ejecutado como "nobody" por el servidor web, pero SUID a "root" se ejecuta como "root". Ello permite, entre otras cosas, que el script haga un "chroot" y se restrinja a sí mismo dentro de un directorio. Si lo siguiente que hace el script es un "setgid()" y "setuid()" a "nobody", tendremos un script ejecutándose como "nobody" y restringido dentro de un "chroot" sin necesidad de acotar el propio servidor web dentro de esa celda.

También se pueden utilizar los procesos SUID para lo contrario de lo normal: en vez de servirse de ellos para incrementar temporalmente nuestros privilegios, usémoslos para reducirlos. Por ejemplo, yo tengo una serie de programas muy útiles, pero que ejecutados como "root" pueden ser francamente peligrosos. En esos casos el programa está como SUID "nobody", asegurándome así el no cometer ningún error irremediable si lo ejecuto como "root".

El Argobot, por ejemplo (http://www.argo.es/~jcea/irc/argobot.htm), es un programa SUID cuyas tres primeras líneas de código son "chroot()", "setgid()" y "setuid()". El proceso es SUID "root" para poder hacer el "chroot" y, de esta forma, asegurarnos que aunque se comprometa la seguridad del programa no ocurrirá nada grave.

La regla general, no obstante, es librarse de los privilegios lo antes posible. Un proceso SUID debe cambiar a un usuario inocuo en cuanto pueda. El número de línea de código a ejecutar bajo los privilegios debe ser lo menor posible, y deben estudiarse, repasarse y probarse hasta la saciedad. No hay motivo alguno para no hacerlo así.

En los casos en los que un programa requiera privilegios excepcionales de vez en cuando, es preferible dividir el código en dos módulos, uno normal y otro SUID, que es el que se llama cuando es necesario y que debe tener una interfaz muy clara y concisa, un código concienzudamente revisado y ser lo más corto posible.

Puedes comprobar los programas SUID en un árbol del directorio tecleando "find . -perm -4000 -print".

Un último detalle: nunca utilices scripts shell SUID, ya que existe una "race condition" que permitiría ejecutar cualquier programa como SUID.