Cómo funcionan los permisos SUID

Como ya sabremos, los ficheros "setuidados" (bonito palabro) son aquellos que tienen alguno de los bits de suid o sgid activos en la información de los permisos de un archivo. Esta información se encuentra en la metainformación vinculada a cada fichero, concretamente en lo que se conoce como el inodo.

Tradicionalmente los sistemas UNIX han utilizado sistemas de archivos que utilizaban la abstracción del inodo. En un inodo se almacena la información relevante a un archivo como el número de enlaces, permisos, propietario, bytes que ocupa, etc y lo más importante: en qué bloques se encuentra (no, el nombre de archivo no se almacena en el inodo). Para dar soporte a múltiples sistemas de archivos, Linux creó el Virtual File System o VFS, que consiste en una abstracción que define una serie de estructuras y de interfaces que los desarrolladores de sistemas de archivos deberán implementar para poder integrarlos en Linux. Esta abstracción mantiene el inodo como elemento fundamental.

Podemos encontrar la definición de dicha estructura en fs.h:

Nótese que sólo he incluido la información más relevante, entre la que tenemos un campo i_mode y los campos i_uid y i_gid. Los dos últimos campos se corresponden obviamente con los identificadores del propietario y grupo del fichero. El campo i_mode contiene la información que andamos buscando.

Si nos fijamos, viene definido por el tipo oscuro umode_t que en realidad es un unsigned short que son 2 bytes o lo que es lo mismo, 16 bits. En estos bits se codifica multitud de información sobre el fichero, observando las macros del fichero stat.h podemos conocer qué información contiene. Nuevamente muestro a continuación únicamente la información relevante:

Si los números empezasen por 0x en C indicarían que se encuentran en hexadecimal, pero en este caso empiezan por 0, lo que significa que están en formato octal.

Vamos a distribuir los dos bytes agrupando de 3 en 3 y esto ya tiene pinta de algo a lo que estamos bastante acostumbrados:

Lo que nos interesa para nuestro caso son los bits especiales, concretamente los que hemos indicado como u o g que se corresponderán a los bit suid y sgid.

Llegados a este punto, ya hemos visto dónde tenemos esta información, pero antes de ver cómo el sistema operativo la interpreta cuando ejecuta un binario, deberemos conocer cómo es la información de seguridad de un proceso.

Los procesos y no los usuarios, son los que realmente utilizan los servicios del sistema operativo y acceden a sus recursos. Será responsabilidad del sistema operativo determinar si un proceso puede o no realizar una determinada operación. Para tomar esta decisión, entre otras cosas, utilizará la información de seguridad del proceso.

Los procesos (y los hilos) se implementan mediante la estructura de datos task_struct que se encuentra en sched.h. En dicha estructura de datos se encuentra un campo cred que contiene un puntero a una estructura de datos tipo cred que *alberga la información de contexto de seguridad. Podemos encontrar su definición en cred.h.

Si analizamos un extracto de la estructura tenemos la siguiente información:

Aunque es evidente su traducción, por enumerarlos tenemos:

Posteriormente veremos qué función tienen cada uno de estos campos, pero antes…​ ¿cómo podemos ver esta información para un proceso existente?, pues simplemente bastará con consultar el fichero status del proceso en /proc. Por ejemplo si quisiera ver para el proceso 22631 sería:

Vemos que las filas Uid: y Gid contiene varias columnas. El orden en que deben interpretarse es el siguiente: rxid, exid, sxid, fsxid (de ahora en adelante pondré una x para representar u o g). Además obsérvese la columna Groups: que contiene multitud de identificadores, estos son todos los grupos a los que "pertenecerá" el proceso para las comprobaciones de seguridad de grupo (nótese que estos grupos coinciden con los que el usuario pertenece).

En nuestros programas en espacio de usuario podremos obtener también la información en tiempo de ejecución del proceso. Valga de ejemplo el siguiente programa.

Todo esto está bien, ya conocemos que para un proceso la información de seguridad no se limita al uid y gid, sino que existen además otros identificadores como el euid o el seuid…​

Para realizar las comprobaciones de seguridad el sistema operativo utilizará los campos euid y egid. Para el caso concreto de acceso a ficheros se comprobarán los campos fsuid y fsgid. Además, si cualquier comprobación necesitara la pertenencia a un grupo, también se comprobará si el grupo requerido se encontrase en la lista alojada en group_info.

Pero veamos un ejemplo de comprobación de seguridad en el kernel. Para ello veremos la más sencilla de las llamadas al sistema que fija el tiempo, la llamada stime y que encontramos definida en time.c

Podemos ver que en la función existe una llamada a security_settime. En dicha función será donde se realizará la comprobación de seguridad, que acabará llamando (mediante los mecanismos definidos en LSM) a cap_settime, que se encuentra en commoncap.c

Para entender este artículo nos bastará asumir que la función capable devolverá cierto si el euid == 0, es decir, si el identificador efectivo es el uid del usuario root (que como sabrás es 0). Volveremos a esto en otro artículo en el que hablaré sobre las capabilities.

Para el caso de archivos, se realizará algo similar: en las llamadas al sistema de manejo de archivos, se comprobará que tiene los permisos adecuados pero comprobando contra los identificadores fsuid, fsgid y la lista de group_info.

Ya hemos visto para qué sirven los exid y fsxid, pero ¿para que sirven entonces los identificadores "grabados" o saved xid?, pues bien, nos servirán para poder cambiar el identificador efectivo al real dentro de un proceso sin perderlo, pudiendo volver a fijar el identificador efectivo posteriormente. ¿Y para qué querríamos cambiar el identificador efectivo?. Pues, por ejemplo, para realizar una operación privilegiada y después devolver al proceso al mínimo privilegio.

Bien, ya hemos visto la información de seguridad que tiene un proceso, pero todavía no os he respondido cómo lo hace un binario suid y por qué no funcionan con los scripts. Tranquilidad, que ya casi estamos, pero antes…​

Como administradores de sistemas, sabemos que Linux siempre crea los procesos mediante un mecanismo de clonación del proceso que realiza la llamada al sistema fork a un nuevo proceso (realmente es la llamada al sistema clone pero eso ya es otra historia ;) ). En dicha clonación se realizará también la copia de los valores que vimos de la estructura cred en el nuevo proceso.

Podemos comprobarlo fácilmente con el siguiente programa:

Tras la ejecución podemos ver que los identificadores son idénticos en ambos procesos.

Cuando lo que queremos es ejecutar un nuevo programa, podemos hacerlo utilizando alguna de las llamadas al sistema de la familia exec que reemplazará el mapa de memoria del proceso, sustituyendo también el segmento de programa por el del binario que se quiere ejecutar.

De este modo cuando una shell ejecuta un programa lo que hará será crear un nuevo proceso con la llamada el sistema fork y posteriormente una llamada al sistema exec con el que reemplazará el programa del proceso. Pero en el caso de la llamada al sistema exec, ésta podrá modificar la información de la estructura cred que vimos con anterioridad a partir de los bits de la estructura inode del fichero.

Antes de ver cómo lo realiza, veamos qué ocurre ejecutando un binario getids "setuidado" llamdado desde el siguiente programa:

Con esto hemos visto cómo se crean los procesos y se copia la información de seguridad. Vayamos a la madre del cordero…​

Si has llegado hasta aquí falta un último esfuerzo, vayamos a ver la llamada al sistema execve en exec.c.

En esta llamada al sistema se llama a la función do_execve con el path al binario a ejecutar y los argumentos. En dicha función se llama posteriormente a la función do_execveat_common. Esta función contiene la lógica principal de ejecución de la familia de funciones exec. En dicha función se emplea una estructura de datos llamada linux_binprm en la que se almacenará la información relevante para la ejecución del binario ejecutado. Podemos encontrar su definición el el fichero binfmts.h.

En la función do_execveat_common vemos que allí se llama a prepare_binprm y en dicha función se llama a bprm_fill_uid y security_bprm_set_creds. En la primera de las funciones es donde se realiza la carga de la información de usuario del inodo al nuevo proceso, como podemos ver a continuación en el fichero exec.c.

He suprimido algunas partes de la función para que se vea más claramente lo que nos importa. En primer lugar, fijémonos que se hace una llamada a la función mnt_may_suid. Esto comprobará si el punto de montaje en el que se encuentra el fichero permite el uso de ficheros con este bit y en caso negativo no continuará con la ejecución.

La segunda llamada task_no_new_privs chequeará si el bit PFA_NO_NEW_PRIVS está activo dentro del campo atomic_flags del proceso.

Finalmente se leerá los datos de uid, gid y mode que vimos anteriormente del inodo y los asignará a los campos euid y egid si el modo incluye los bits de S_ISUID y S_ISGID. En el caso del egid chequeará también que el grupo tenga permisos de ejecución con la macro S_IXGRP.

Vemos que se copian al efectivo, pero ¿se copian al suid, sgid, fsuid y fsgid?. Bueno esto dependerá del módulo LSM. Concretamente se hace en la llamada a security_bprm_set_creds, que llamará al hook establecido en security_ops→bprm_set_creds.

En la implementación "base" tenemos la función cap_bprm_set_creds en common.cap en la que se realiza la copia como vemos a continuación:

Llegados a este punto, hemos visto cómo se han copiado los datos de estos bits a la estructura de tipo linux_binprm. Pero…​ ¡todavía no se han copiado al proceso!.

Por fin llegamos a la respuesta a esta pregunta. Pues bien, la copia de la información de la estructura linux_binprm al proceso se realiza en la implementación concreta del tipo de binario soportado por el kernel. Como podíamos suponer, linux_binprm es una abstracción que tiene por objetivo dar soporte a distintos tipos de binario en el kernel. Podemos ver los tipos soportados en el directorio /source/fs, aquellos que empiezan por binfmt_. Allí encontramos:

En cada uno de estos archivos se registra el formato de binario que soporta y al menos define una función que realiza la tarea "dura" de adecuar el mapa de memoria a la estructura definida por el binario. Además, incluye antes de realizar cualquier tipo de operación la lógica que determina si el fichero pasado es un binario del tipo soportado. En el caso de los scripts es muy fácil porque contiene la secuencia conocida como Shebang.

Como vemos, si no contiene la secuencia #! al principio no continuará con la carga del binario pasado.

La copia de las credenciales de la estructura linux_binprm a cred del task_struct se realizan en la función install_exec_creds dentro del fichero exec.c que llamará a commit_creds.

Pues bien, por motivos de seguridad la función install_exec_creds se llama únicamente desde los módulos que soportan los formatos flat, aout y elf como puede verse aquí. Por lo tanto, este es el motivo por el cual cuando el kernel ejecuta un script no funcionan los bits de suid y sgid.

Espero que te haya gustado y que esta explicación te haya hecho más feliz, ;) Happy hacking!