Permisos especiales

1. Tres problemas pendientes

Cada uno de estos casos apareció en un tema anterior, y en cada uno el modelo de dueño, grupo y otros se queda corto:

Son tres mecanismos distintos, con tres propósitos distintos, que comparten una ubicación: se guardan junto a los permisos, en el inodo, y se manejan con chmod.

2. Tres bits más

Además de los nueve permisos, cada archivo tiene tres indicadores de sí o no. Como no hay lugar para ellos en la cadena de nueve caracteres, ls -l los muestra en la posición de la x de cada trío, cambiando la letra:

La letra reemplaza a la x, pero no la elimina. Una s o una t minúsculas significan «el permiso especial y la ejecución». El caso en que la ejecución falta se muestra con mayúscula, y lo vemos en la sección 10.

3. setuid: ejecutar como el dueño

En el tema 16 establecimos la regla de la herencia: un programa corre con la identidad de quien lo lanza. El primer permiso especial es la excepción a esa regla.

El bit setuid (set user ID), aplicado a un programa, hace que se ejecute con la identidad del dueño del archivo, y no con la del usuario que lo lanza.

El ejemplo de siempre es el comando para cambiar la contraseña:

$ ls -l /usr/bin/passwd /etc/shadow
-rw-r----- 1 root shadow  1523 oct 12 18:02 /etc/shadow
-rwsr-xr-x 1 root root   64152 abr  9  2024 /usr/bin/passwd

El archivo de contraseñas solo admite escritura de root. El programa passwd pertenece a root, cualquiera puede ejecutarlo —el trío de los otros es r-x— y lleva una s donde iría la x del dueño. Las tres cosas juntas resuelven el problema: cuando ana ejecuta passwd, el proceso corre como root, y puede modificar /etc/shadow.

Esto no le da a ana el poder de root. Le da el poder de root para hacer lo que ese programa hace, y el programa fue escrito para hacer una sola cosa: pedir la contraseña actual, verificarla, y cambiar la línea del usuario que lo ejecuta, y ninguna otra. La decisión de qué se permite no está en los permisos, sino en el código del programa.

4. El setuid en acción

Se puede ver el cambio de identidad con dos terminales. En la primera se inicia passwd y se lo deja esperando en su primera pregunta; en la segunda se mira el proceso:

$ passwd
Changing password for ana.
Current password: ← se lo deja aquí, sin escribir nada

$ ps -o user,ruser,cmd -C passwd
USER     RUSER    CMD
root     ana      passwd

Luego se cancela el passwd de la primera terminal con Ctrl+C. El listado muestra dos identidades para un mismo proceso, y es la precisión que faltaba en el modelo del tema 16:

En un proceso normal las dos coinciden. El bit setuid las separa: el usuario real sigue siendo ana, y el efectivo pasa a ser el dueño del archivo.

Así funciona, de paso, la herramienta del tema 19. sudo no tiene nada de mágico: es un programa setuid de root, que antes de usar ese privilegio comprueba en sudoers si quien lo lanzó tiene derecho.

$ ls -l /usr/bin/sudo /usr/bin/su
-rwsr-xr-x 1 root root  55680 abr  9  2024 /usr/bin/su
-rwsr-xr-x 1 root root 277936 abr  8  2024 /usr/bin/sudo

5. Un permiso de cuidado

Un programa setuid de root es una puerta al privilegio máximo que cualquier usuario puede empujar. Es segura solo si el programa hace exactamente lo previsto, ante cualquier entrada. Un defecto en uno de ellos —una opción que permite escribir en un archivo elegido por el usuario, un dato sin validar— se convierte en una vía para tomar el control del equipo. Por eso son pocos, están escritos con especial cuidado, y son lo primero que revisa una auditoría de seguridad.

$ find /usr/bin -perm -4000
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount

Varios son conocidos: chsh y chfn, que modifican la propia línea de /etc/passwd; su y sudo; mount, que permite a un usuario conectar una memoria USB. Todos responden al mismo patrón: una operación que requiere privilegio, ofrecida a todos de manera acotada.

El sistema tiene dos defensas propias. En los scripts, el bit setuid se ignora: solo vale para programas compilados, porque un script con privilegios es demasiado fácil de manipular. Y cuando un usuario común modifica un archivo setuid, el bit se borra solo, para que nadie pueda cambiarle el contenido a un programa privilegiado.

El bit se pone y se quita con chmod, con la letra s aplicada al dueño:

6. setgid en archivos

El segundo permiso especial es el equivalente para los grupos:

El bit setgid (set group ID), aplicado a un programa, hace que se ejecute con el grupo del archivo como grupo efectivo.

$ ls -l /usr/bin/crontab /usr/bin/chage
-rwxr-sr-x 1 root shadow  72184 abr  9  2024 /usr/bin/chage
-rwxr-sr-x 1 root crontab 39664 mar 31  2024 /usr/bin/crontab

Es una forma más moderada del mismo recurso. chage, que usamos en el tema anterior, necesita leer /etc/shadow para que un usuario consulte la vigencia de su contraseña. En lugar de correr como root, corre con el grupo shadow, que tiene lectura sobre ese archivo y nada más. Si el programa tuviera un defecto, el daño posible sería mucho menor.

Es el principio de mínimo privilegio aplicado al diseño de los programas: cuando alcanza con un grupo, no se usa root.

7. setgid en directorios: heredar el grupo

En un directorio, el mismo bit significa otra cosa, y es su uso más frecuente:

En un directorio con el bit setgid, todo archivo o subdirectorio que se cree dentro recibe el grupo del directorio, en lugar del grupo primario de quien lo crea.

Lo comprobamos en un taller, usando el grupo users, al que ana pertenece:

$ cd ~/practica
$ mkdir -p taller/equipo
$ cd taller
$ chgrp users equipo
$ touch equipo/antes.txt            # sin el bit: grupo primario de ana
$ chmod g+s equipo
$ ls -ld equipo
drwxrwsr-x 2 ana users 4096 oct 12 18:30 equipo
$ touch equipo/despues.txt          # con el bit: grupo del directorio
$ mkdir equipo/sub
$ ls -l equipo
total 4
-rw-rw-r-- 1 ana ana      0 oct 12 18:29 antes.txt
-rw-rw-r-- 1 ana users    0 oct 12 18:31 despues.txt
drwxrwsr-x 2 ana users 4096 oct 12 18:31 sub

Tres cosas para observar. El archivo creado antes conserva su grupo: el bit actúa sobre lo que se crea a partir de entonces, no sobre lo existente. El archivo creado después pertenece a users, sin que nadie ejecutara chgrp. Y el subdirectorio no solo heredó el grupo: heredó también el bit, de modo que el comportamiento se propaga a todo el árbol que crezca debajo.

8. El directorio compartido, resuelto

Con esto se completa el ejemplo que quedó abierto en el tema 20. Allí, el archivo que un miembro creaba en /srv/proyecto quedaba con su grupo privado, y los demás no podían modificarlo. La receta completa de un directorio de trabajo para un grupo tiene tres pasos:

sudo mkdir /srv/proyecto
sudo chgrp proyecto /srv/proyecto
sudo chmod 2770 /srv/proyecto         # rwxrws---: el 2 inicial es el setgid

La última fila explica por qué Ubuntu usa 002 como máscara por defecto, según vimos en el tema 18. Combinada con los grupos privados, hace que los directorios compartidos funcionen sin ajustes: fuera de ellos, la escritura del grupo no concede nada a nadie, porque el grupo es privado; dentro, el grupo es el del equipo, y todos pueden editar. Donde la máscara es 022, hace falta un recurso más, que veremos en la sección 14.

9. El bit adhesivo

El tercer permiso especial se aplica a los directorios donde escriben muchos usuarios que no confían entre sí. El caso típico lo tenemos a la vista desde el tema 8:

$ ls -ld /tmp
drwxrwxrwt 18 root root 4096 oct 12 18:20 /tmp

Los tres tríos tienen rwx: cualquiera puede crear archivos. Según la regla del tema 17, eso implicaría que cualquiera puede también borrar los archivos de los demás, porque borrar depende del directorio. La t final lo impide:

En un directorio con el bit adhesivo, un archivo solo puede ser borrado o renombrado por su dueño, por el dueño del directorio, o por root, aunque otros usuarios tengan permiso de escritura sobre el directorio.

Lo probamos creando en /tmp un archivo que pertenezca a otro usuario, e intentando borrarlo:

$ sudo -u nobody touch /tmp/ajeno.txt
$ ls -l /tmp/ajeno.txt
-rw-r--r-- 1 nobody nogroup 0 oct 12 18:40 /tmp/ajeno.txt
$ rm -f /tmp/ajeno.txt
rm: cannot remove '/tmp/ajeno.txt': Operation not permitted
$ sudo rm /tmp/ajeno.txt            # root sí puede

ana tiene escritura en /tmp, y sin el bit habría podido borrar el archivo. El mensaje es Operation not permitted y no Permission denied, con el matiz que aprendimos en el tema 18: no es que falte un permiso, sino que la operación está reservada al dueño.

El bit no impide modificar el contenido de un archivo ajeno: eso lo siguen decidiendo los permisos del archivo. Protege los nombres, no los datos.

El nombre, en inglés sticky bit, viene de su función original en los primeros Unix: aplicado a un programa, lo dejaba «pegado» en la memoria después de terminar, para que arrancara más rápido la vez siguiente. Ese uso desapareció hace décadas; quedó el nombre, y el bit se recicló para los directorios.

10. La S y la T mayúsculas

Como el permiso especial ocupa en el listado el lugar de la x, hace falta distinguir dos situaciones: el bit con ejecución, y el bit sin ella. Se usa la caja de la letra:

$ touch prueba
$ chmod 4644 prueba                 # setuid, pero sin ejecución
$ ls -l prueba
-rwSr--r-- 1 ana ana 0 oct 12 18:45 prueba
$ chmod u+x prueba
$ ls -l prueba
-rwsr--r-- 1 ana ana 0 oct 12 18:45 prueba

Un setuid sobre un archivo que no se puede ejecutar no sirve para nada, y la mayúscula está para llamar la atención sobre eso. Suele ser la huella de un chmod numérico mal calculado, o de haber quitado la x sin quitar el bit.

11. El cuarto dígito

En el tema 18 vimos que stat y chmod -v muestran los permisos con cuatro dígitos, como 0644, y dijimos que el primero se explicaría aquí. Es un dígito más, que se calcula igual que los otros, sumando los valores de los tres bits especiales:

La última fila es un caso legítimo de mayúscula: el bit adhesivo está, y los otros no tienen x porque el directorio está cerrado para ellos.

Un detalle práctico de chmod: en los directorios, un número de tres dígitos como 755 no quita un setgid existente. Es una precaución para no deshacer por descuido un directorio compartido. Para quitarlo hay que decirlo: chmod g-s directorio.

12. Auditar los permisos especiales

Como estos bits conceden privilegios, saber dónde están forma parte de administrar un sistema. find, con su condición -perm, los localiza:

El guion delante del número significa «que tenga al menos estos bits»; la barra, «que tenga alguno de estos». Sin signo, find buscaría los permisos exactos.

La utilidad está en la comparación. Se guarda la lista de programas setuid de un sistema recién instalado, y se la contrasta periódicamente con la actual: un nombre nuevo que no corresponde a ningún paquete instalado merece una investigación inmediata. Las herramientas para guardar una salida en un archivo y comparar dos archivos son las de los bloques 5 y 6.

Hay además una tendencia a reducir el uso del setuid. Los sistemas actuales tienen mecanismos más finos, que conceden a un programa un privilegio determinado —por ejemplo, abrir cierto tipo de conexión de red— sin darle la identidad completa de root. De ahí que la lista de la sección 5 sea hoy más corta que hace unos años.

13. Listas de control de acceso

Queda un límite del modelo que los bits especiales no tocan, y que señalamos en el tema 17: solo hay tres clases. No hay forma de decir «este usuario sí, y aquel no» cuando ninguno de los dos es el dueño ni conviene crear un grupo para la ocasión. Para eso existe un mecanismo complementario:

Una lista de control de acceso, o ACL (access control list), es un conjunto de reglas adicionales, asociadas a un archivo, que otorgan permisos a usuarios y grupos determinados, más allá del dueño, el grupo y los otros.

Se manejan con dos comandos: getfacl las muestra y setfacl las modifica. Si no están, se instalan con sudo apt install acl. Preparamos un archivo cerrado a los otros, en /tmp para que cualquier usuario pueda llegar hasta él:

$ mkdir /tmp/acl
$ echo "Reservado" > /tmp/acl/dato.txt
$ chmod 640 /tmp/acl/dato.txt
$ sudo -u www-data cat /tmp/acl/dato.txt          # un «otro» cualquiera: no puede
cat: /tmp/acl/dato.txt: Permission denied

Ahora concedemos la lectura a ese usuario, y solo a él:

$ setfacl -m u:www-data:r /tmp/acl/dato.txt
$ sudo -u www-data cat /tmp/acl/dato.txt          # ahora sí
Reservado
$ sudo -u nobody cat /tmp/acl/dato.txt            # los demás siguen sin poder
cat: /tmp/acl/dato.txt: Permission denied
$ ls -l /tmp/acl/dato.txt
-rw-r-----+ 1 ana ana 10 oct 12 18:55 /tmp/acl/dato.txt

setfacl -m u:www-data:r dato.txt
        │  │ │        │
        │  │ │        └─ qué permisos: lectura
        │  │ └─ a quién: ese usuario
        │  └─ qué clase: u, un usuario; g, un grupo
        └─ -m: modificar, es decir, agregar o cambiar una regla

El signo + al final de la cadena de ls -l es el aviso que anticipamos: los nueve caracteres ya no cuentan toda la historia. El detalle lo da getfacl:

$ getfacl /tmp/acl/dato.txt
getfacl: Removing leading '/' from absolute path names
# file: tmp/acl/dato.txt
# owner: ana
# group: ana
user::rw-
user:www-data:r--
group::r--
mask::r--
other::---

Las líneas sin nombre —user::, group::, other::— son los tres tríos de siempre, escritos de otra forma. La línea resaltada es la regla agregada.

14. ACL: máscara, herencia y límites

Dos conceptos completan la lectura de la salida de getfacl.

La máscara, la línea mask::, es un tope: ninguna regla con nombre, ni el grupo, puede tener en la práctica más permisos que los que ella indica. Cuando un archivo tiene ACL, el trío central de ls -l deja de mostrar los permisos del grupo y pasa a mostrar la máscara, lo que puede despistar. Y un chmod sobre el grupo modifica la máscara, con lo que puede recortar de golpe todas las reglas.

Las reglas por defecto, de la última fila de la tabla, son para los directorios lo que el setgid es para el grupo: definen qué ACL recibirá cada archivo nuevo. Son la pieza que faltaba en la sección 8 para los sistemas con máscara 022: con una regla por defecto que dé rwX al grupo, los archivos nacen editables por todo el equipo, sea cual sea la máscara de cada usuario.

Las ACL son potentes, y por eso mismo conviene usarlas con moderación:

El criterio es usar los tres tríos y los grupos mientras alcancen, que es casi siempre, y reservar las ACL para las excepciones que no se pueden expresar de otro modo.

Dejamos todo como estaba:

$ rm -r /tmp/acl
$ cd ~/practica
$ rm -r taller
$ ls
fotos  informe.txt  notas.txt  tareas.txt

15. El bloque en una página

Con este tema termina el cuarto bloque. Sus seis temas forman un solo razonamiento, que conviene ver junto:

Y la referencia del tema:

Hasta aquí usamos los comandos de a uno, y solo de pasada los conectamos entre sí con una barra vertical o enviamos su salida a un archivo. El quinto bloque está dedicado a eso, que es lo que da a la línea de comandos su verdadera potencia. Empieza en el tema 22, con los tres canales por los que todo comando recibe y entrega datos.

16. Resumen

• Además de los nueve permisos hay tres bits especiales, que ls -l muestra en la posición de la x: s en el trío del dueño, s en el del grupo y t en el de los otros.
• Un programa con setuid se ejecuta con la identidad del dueño del archivo. Así passwd, que es de root, puede modificar /etc/shadow.
• Un proceso tiene un usuario real, quien lo lanzó, y uno efectivo, con el que se evalúan los permisos. El setuid los separa.
• sudo y su son programas setuid de root.
• El setuid es un riesgo: un defecto en uno de esos programas da acceso a root. No se aplica a programas de uso general, y en los scripts se ignora.
• Un programa con setgid se ejecuta con el grupo del archivo, una forma más limitada de privilegio.
• En un directorio con setgid, lo que se crea hereda el grupo del directorio, y los subdirectorios heredan además el bit.
• Un directorio compartido se arma con el grupo del equipo y permisos 2770.
• En un directorio con el bit adhesivo, como /tmp, solo el dueño de cada archivo puede borrarlo o renombrarlo.
• Una S o una T mayúsculas indican el bit especial sin el permiso de ejecución.
• En notación octal, los bits especiales forman un cuarto dígito inicial: 4 setuid, 2 setgid, 1 adhesivo.
• find -perm -4000 y -perm -2000 localizan los programas con estos bits, para auditarlos.
• Las ACL otorgan permisos a usuarios y grupos determinados. Se consultan con getfacl, se modifican con setfacl, y se delatan con un + en ls -l.

17. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta ls -l /usr/bin/passwd /usr/bin/sudo /usr/bin/crontab y ls -ld /tmp /var/tmp. Identifica en cada línea el permiso especial y explica para qué está.
2. Repite la experiencia de la sección 4 con dos terminales, y observa las columnas USER y RUSER.
3. Lista los programas setuid y setgid de /usr/bin y de /usr/sbin con find. Elige tres que no conozcas y averigua qué hacen con whatis.
4. En un directorio de pruebas, crea un subdirectorio, cámbiale el grupo a otro de los tuyos y activa el setgid. Crea dentro archivos y subdirectorios, y comprueba qué grupo y qué bits reciben.
5. Sobre ese directorio ejecuta chmod 755 y mira si el setgid sigue. Quítalo luego con chmod g-s.
6. Crea en /tmp un directorio con permisos 777 y, con sudo -u nobody, un archivo dentro. Bórralo como tu usuario. Repite después de activar el bit adhesivo en el directorio, y compara.
7. Crea un archivo con permisos 4644, 2644 y 1644 sucesivamente, mirando cada vez la cadena con ls -l y el número con stat -c '%a %A'.
8. Busca en el sistema directorios con escritura para todos y sin bit adhesivo, con el último comando de la tabla de la sección 12. ¿Hay alguno?
9. Reproduce el ejemplo de ACL de la sección 13. Luego quita la regla con setfacl -x, comprueba que el acceso volvió a negarse, y elimina toda la lista con setfacl -b.
10. En un directorio de pruebas, define una ACL por defecto con setfacl -d -m g:users:rwX, crea un archivo dentro y examínalo con getfacl. ¿Qué heredó?