Cómo usar SUID, SGID y Sticky Bits en Linux

• Dave McKay

  @TheGurkha

• 26 de febrero de 2020, 8:00am EDT

SUID, SGID, y Sticky Bits son poderosos permisos especiales que puede establecer para los ejecutables y directorios en Linux. Compartiremos los beneficios -y las posibles dificultades- de su uso.

Ya están en uso

Construir la seguridad en un sistema operativo multiusuario presenta varios dilemas. Por ejemplo, el concepto (aparentemente) básico de las contraseñas. Todas tienen que ser almacenadas para que cada vez que alguien se conecte, el sistema pueda comparar la contraseña que escribe con la copia almacenada. Obviamente, como las contraseñas son las llaves del reino, deben ser salvaguardadas.

En Linux, las contraseñas almacenadas están protegidas de dos maneras: están encriptadas, y sólo alguien con privilegios root puede acceder al archivo que contiene las contraseñas. Eso puede sonar bien, pero presenta un dilema: si sólo las personas con privilegios root pueden acceder a las contraseñas almacenadas, ¿cómo hacen los que no tienen ese acceso para cambiar sus contraseñas?

Elevando su estado

Por lo general, los comandos y programas de Linux se ejecutan con el mismo conjunto de permisos que la persona que lanza el programa. Cuando root ejecuta el comando passwd para cambiar una contraseña, se ejecuta con los permisos de root. Eso significa que el comando passwd puede acceder libremente a las contraseñas almacenadas en el archivo /etc/shadow.

Lo que sería ideal es un esquema en el que cualquier persona en el sistema podría lanzar el programa passwd, pero que el programa passwd mantenga los privilegios elevados de root. Esto permitiría a cualquiera cambiar su propia contraseña.

El escenario anterior es precisamente lo que hace el bit Set User ID (SUID). Ejecuta programas y comandos con los permisos del propietario del archivo, en lugar de los permisos de la persona que lanza el programa.

Está elevando el estado del programa

Sin embargo, hay otro dilema. Hay que evitar que la persona se entrometa con la contraseña de otra persona. Linux incorpora el esquema SUID que le permite ejecutar aplicaciones con un conjunto de permisos prestados temporalmente-pero eso es sólo la mitad de la historia de la seguridad.

El mecanismo de control que impide que alguien trabaje con la contraseña de otra persona está contenido dentro del programa passwd, no el sistema operativo y el esquema SUID.

Los programas que se ejecutan con privilegios elevados pueden plantear riesgos de seguridad si no se crean con una mentalidad de «seguridad por diseño». Eso significa que la seguridad es lo primero que se considera, y luego se construye sobre eso. No escriba su programa y luego intente darle una capa de seguridad.

La mayor ventaja del software de código abierto es que puede mirar el código fuente usted mismo o consultar revisiones de confianza del mismo. En el código fuente del programa passwd, hay comprobaciones, por lo que se puede ver si la persona que ejecuta el programa es root. Se permiten diferentes capacidades si alguien es root (o alguien que usa sudo).

Este es el código que detecta si alguien es root.

El siguiente es un ejemplo en el que se tiene en cuenta. Como root puede cambiar cualquier contraseña, el programa no tiene que molestarse en hacer las comprobaciones que suele hacer para ver qué contraseñas tiene permiso para cambiar la persona. Así que, para root, se salta esas comprobaciones y sale de la función de comprobación.

Con los comandos y utilidades principales de Linux, puedes estar seguro de que tienen seguridad incorporada y que el código ha sido revisado muchas veces. Por supuesto, siempre existe la amenaza de exploits aún desconocidos. Sin embargo, los parches o las actualizaciones no tardan en aparecer para contrarrestar cualquier vulnerabilidad recién identificada.

Es el software de terceros -especialmente el que no es de código abierto- con el que hay que tener mucho cuidado. No estamos diciendo que no lo haga, pero, si lo hace, debe asegurarse de que no expondrá su sistema a riesgos. Usted no quiere elevar los privilegios de un programa que no va a auto-gobernarse correctamente y la persona que lo ejecuta.

Comandos de Linux que usan SUID

Los siguientes son algunos de los comandos de Linux que usan el bit SUID para dar al comando privilegios elevados cuando es ejecutado por un usuario normal:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Note que los nombres de los archivos están resaltados en rojo, lo que indica que el bit SUID está activado.

Los permisos de un archivo o directorio suelen estar representados por tres grupos de tres caracteres: rwx. Estos significan lectura, escritura y ejecución. Si las letras están presentes, ese permiso ha sido concedido. Sin embargo, si hay un guión (-) en lugar de una letra, ese permiso no se ha concedido.

Hay tres grupos de estos permisos (de izquierda a derecha): los del propietario del archivo, los de los miembros del grupo del archivo y los de otros. Cuando el bit SUID se establece en un archivo, una «s» representa el permiso de ejecución del propietario.

Si el bit SUID se establece en un archivo que no tiene capacidad de ejecución, una «S» mayúscula denota esto.

Vamos a ver un ejemplo. El usuario normal dave escribe el comando passwd:

passwd

El comando passwd solicita a dave su nueva contraseña. Podemos utilizar el comando ps para ver los detalles de los procesos en ejecución.

Usaremos ps con grep en una ventana de terminal diferente y buscaremos el proceso passwd. También usaremos las opciones -e (cada proceso) y -f (formato completo) con ps.

Escribimos el siguiente comando:

ps -e -f | grep passwd

Se reportan dos líneas, la segunda de las cuales es el proceso grep buscando comandos con la cadena «passwd» en ellos. Sin embargo, es la primera línea la que nos interesa, porque es la del proceso passwd lanzado por dave.

Podemos ver que el proceso passwd se ejecuta igual que si root lo hubiera lanzado.

Configuración del bit SUID

Es fácil cambiar el bit SUID con chmod. El modo simbólico u+s establece el bit SUID y el modo simbólico u-s borra el bit SUID.

Para ilustrar algunos de los conceptos del bit SUID, creamos un pequeño programa llamado htg. Está en el directorio raíz del usuario dave, y no tiene el bit SUID activado. Cuando se ejecuta, muestra los ID de usuario (UID) real y efectivo.

El UID real pertenece a la persona que lanzó el programa. El UID efectivo es la cuenta con la que el programa se comporta como si hubiera sido lanzado por ella.

Escribimos lo siguiente:

ls -lh htg

./htg

Cuando ejecutamos la copia local del programa, vemos que tanto el UID real como el efectivo son dave. Así que se comporta como un programa normal.

Copiémoslo en el directorio /usr/local/bin para que otros puedan utilizarlo.

Escribimos lo siguiente, usando chmod para fijar el bit SUID, y luego comprobamos que se ha fijado:

sudo cp htg /usr/local/bin

sudo chmod u+s /usr/local/bin/htg

ls -hl /usr/local/bin/htg

Así, el programa está copiado, y el bit SUID está fijado. Vamos a ejecutarlo de nuevo, pero esta vez ejecutaremos la copia en la carpeta /usr/local/bin:

htg

Aunque dave lanzó el programa, el ID efectivo se establece en el usuario root. Por lo tanto, si mary lanza el programa, sucede lo mismo, como se muestra a continuación:

htg

El ID real es mary, y el ID efectivo es root. El programa se ejecuta con los permisos del usuario root.

Relacionado: Cómo usar el comando chmod en Linux

El bit SGID

El bit Set Group ID (SGID) es muy similar al bit SUID. Cuando el bit SGID se establece en un archivo ejecutable, el grupo efectivo se establece en el grupo del archivo. El proceso se ejecuta con los permisos de los miembros del grupo del archivo, en lugar de los permisos de la persona que lo lanzó.

Ajustamos nuestro programa htg para que también muestre el grupo efectivo. Cambiaremos el grupo del programa htg para que sea el grupo por defecto del usuario mary, mary. También utilizaremos los modos simbólicos u-s y g+s con chown para eliminar el bit SUID y establecer el SGID.

Para ello, escribimos lo siguiente:

sudo chown root:mary /usr/local/bin/htg

sudo chmod u-s,g+s /usr/local/bin/htg

ls -lh /usr/local/bin/htg

Puedes ver el bit SGID denotado por la «s» en los permisos de grupo. Además, observa que el grupo está configurado como mary y que el nombre del archivo está ahora resaltado en amarillo.

Antes de ejecutar el programa, vamos a establecer a qué grupos pertenecen dave y mary. Utilizaremos el comando id con la opción -G (grupos), para imprimir todos los identificadores de grupo. A continuación, ejecutaremos el programa htg como dave.

Escribimos los siguientes comandos:

id -G dave

id -G mary

htg

El ID del grupo por defecto de mary es 1001, y el grupo efectivo del programa htg es 1001. Por lo tanto, aunque haya sido lanzado por dave, se está ejecutando con los permisos de los miembros del grupo mary. Es lo mismo que si dave se hubiera unido al grupo mary.

Apliquemos el bit SGID a un directorio. Primero, crearemos un directorio llamado «trabajo», y luego cambiaremos su grupo a «geek». A continuación, estableceremos el bit SGID en el directorio.

Cuando usemos ls para comprobar la configuración del directorio, también usaremos la opción -d (directorio) para que veamos los detalles del directorio, no su contenido.

Escribimos los siguientes comandos:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

El bit SGID y el grupo «geek» están activados. Estos afectarán a cualquier elemento creado dentro del directorio work.

Escribimos lo siguiente para entrar en el directorio work, crear un directorio llamado «demo» y comprobar sus propiedades:

cd work

mkdir demo

ls -lh -d demo

El bit SGID y el grupo «geek» se aplican automáticamente al directorio «demo».

Escribamos lo siguiente para crear un archivo con el comando touch y comprobemos sus propiedades:

touch useful.sh

ls -lh useful.sh

El grupo del nuevo archivo se aplica automáticamente a «geek».»

Relacionado: Cómo usar el comando chown en Linux

El bit pegajoso

El bit pegajoso recibe su nombre de su propósito histórico. Cuando se establece en un ejecutable, marca al sistema operativo que las porciones de texto del ejecutable deben mantenerse en swap, haciendo que su reutilización sea más rápida. En Linux, el bit pegajoso sólo afecta a un directorio – establecerlo en un archivo no tendría sentido.

Cuando se establece el bit pegajoso en un directorio, la gente sólo puede eliminar los archivos que le pertenecen dentro de ese directorio. No pueden eliminar los archivos que pertenecen a otra persona, no importa qué combinación de permisos de archivo se establecen en los archivos.

Esto le permite crear un directorio que todos-y los procesos que lanzan-pueden utilizar como almacenamiento de archivos compartidos. Los archivos están protegidos porque, de nuevo, nadie puede borrar los archivos de los demás.

Creemos un directorio llamado «compartido». Usaremos el modo simbólico o+t con chmod para poner el bit sticky en ese directorio. Luego miraremos los permisos de ese directorio, así como de los directorios /tmp y /var/tmp.

Escribimos los siguientes comandos:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Si el bit sticky está establecido, el bit ejecutable del conjunto de permisos de los archivos «otros» se establece en «t». El nombre del archivo también se resalta en azul.

Las carpetas /tmp y /var/tmp son dos ejemplos de directorios que tienen todos los permisos de archivo establecidos para el propietario, el grupo y otros (por eso se resaltan en verde). Se utilizan como ubicaciones compartidas para archivos temporales.

Con esos permisos, cualquiera debería, en teoría, ser capaz de hacer cualquier cosa. Sin embargo, el bit pegajoso los anula, y nadie puede borrar un archivo que no le pertenece.

Recordatorios

Lo siguiente es una lista rápida de lo que hemos cubierto arriba para futuras referencias:

• SUID sólo funciona en archivos.
• Puedes aplicar SGID a directorios y archivos.
• Sólo se puede aplicar el bit pegajoso a los directorios.
• Si los indicadores «s«, «g» o «t» aparecen en mayúsculas, el bit ejecutable (x) no se ha puesto en marcha.