Permisos y control de acceso básico

Cada inodo almacena un UID propietario, un GID propietario y nueve bits de permisos agrupados en tres clases:

Los tres permisos básicos, lectura (r), escritura (w) y ejecución (x), tienen un significado distinto según se apliquen a un archivo regular o a un directorio. Confundirlos es el origen de buena parte de las configuraciones inseguras.

chmod, del inglés change mode, modifica el modo de un archivo, es decir, los doce bits de permisos que se almacenan en su inodo: tres bits especiales, que se estudian en la sección 4, y nueve bits de permisos básicos, que corresponden a la lectura, la escritura y la ejecución de cada una de las tres clases de la sección 1.1. Cada dígito octal agrupa tres de esos bits, como muestra la descomposición del modo 4755 de /usr/bin/passwd:

ls -l muestra este modo como -rwsr-xr-x. Los bits especiales no tienen columna propia y ocupan la posición de la x de cada clase.

Admite dos formas de indicar los permisos: el modo simbólico, que añade, retira o asigna permisos concretos a cada clase, y el modo octal, que fija el modo completo con un número.

Solo el propietario de un archivo, o un proceso con CAP_FOWNER, puede cambiar sus permisos.

chown, del inglés change owner, cambia el usuario propietario de un archivo y, opcionalmente, su grupo propietario. El inodo no guarda nombres, sino el UID y el GID numéricos, que ls -l y stat traducen a nombres consultando las bases de datos de cuentas. Por eso, cuando se elimina una cuenta, sus archivos muestran un número en lugar de un nombre y pasan a ser archivos huérfanos, que se auditan en la sección 8.2.

El primer argumento admite varias formas:

Las opciones más relevantes son las siguientes:

chgrp, del inglés change group, cambia solo el grupo propietario de un archivo. Equivale a chown :grupo, pero expresa con más claridad la intención y es la forma habitual de conceder acceso a un equipo. Se asigna el archivo al grupo y, a continuación, se fijan los permisos de la clase g. Por ejemplo, para que los miembros de auditores puedan leer un registro sin poder modificarlo:

Como ocurre con chown, cambiar el grupo de un ejecutable elimina sus bits SetUID y SetGID, por lo que chgrp debe ejecutarse antes que chmod. En los directorios, en cambio, el bit SetGID se conserva.

El comando umask 027 solo afecta a la shell actual y a sus procesos hijos. Para que la política sea persistente debe configurarse en los mecanismos que inicializan cada tipo de sesión:

El bit SetGID tiene dos efectos distintos según se aplique a un archivo ejecutable o a un directorio. Ambos comparten la misma idea, que es hacer que el grupo determine un comportamiento en lugar del usuario. El segundo uso, SetGID en directorios, es una de las herramientas más útiles para organizar el trabajo en equipo sin recurrir a root ni abrir los archivos a todo el sistema.

El Sticky Bit resuelve un problema que los nueve bits básicos no pueden expresar, el de un directorio donde todos puedan crear archivos, pero nadie pueda borrar los de los demás. Es exactamente lo que hace falta en un directorio compartido como /tmp.

El problema. Recuerde, de la sección 1.2, que borrar un archivo no depende de los permisos del archivo, sino de los del directorio que lo contiene. Hace falta w y x sobre el directorio. En un directorio de escritura pública con modo 777, cualquier usuario tiene esa escritura, así que cualquiera puede borrar o renombrar los archivos de cualquier otro, aunque esos archivos sean 600 y no pueda leerlos. En un directorio como /tmp, por el que pasan los archivos temporales, los sockets y los archivos de bloqueo de todos los usuarios y servicios, esto permitiría borrar el archivo de bloqueo de un servicio, provocar una denegación de servicio o sustituir un archivo que otro proceso va a leer.

La solución. El Sticky Bit añade una restricción al borrado. En un directorio que lo tenga activado, un usuario solo puede eliminar o renombrar un archivo si es su propietario, o el propietario del directorio, o tiene CAP_FOWNER. Todos pueden seguir creando archivos y modificando los propios, pero nadie toca los ajenos.

Históricamente, el bit tenía otro significado. Indicaba al sistema que mantuviese un programa en el área de intercambio para acelerar su carga. En Linux ese uso desapareció y solo queda el efecto sobre directorios.

Los directorios temporales del sistema ya lo traen activado, lo que se ve en la t final de los permisos:

La t ocupa la posición de la x de others. Una t minúscula indica que el directorio conserva el permiso x para others, y una T mayúscula que no lo tiene, lo que en un directorio compartido sería un error, porque nadie podría atravesarlo.

Desde el punto de vista del bastionado, la regla es simple: todo directorio de escritura pública debe tener el Sticky Bit.

Se activa con chmod, en modo simbólico u octal, anteponiendo el 1 a los tres dígitos habituales:

Un binario SetUID de root es una herramienta contundente. Concede todos los privilegios del superusuario a un programa que, casi siempre, solo necesita uno. Como se vio en la sección 4.1, si ese programa tiene un fallo, el atacante hereda el control total del sistema. Las capacidades, o capabilities, son la respuesta del núcleo a ese exceso. Dividen los poderes de root en unidades independientes que pueden concederse por separado.

El núcleo define unas cuarenta capacidades, cuya lista completa figura en la página de manual capabilities(7) y crece con cada versión. La tabla siguiente recoge solo cuatro de las más relevantes para el bastionado, dos de red y dos que equivalen casi por completo a root:

No todas las capacidades representan el mismo riesgo. Algunas, como CAP_NET_BIND_SERVICE, conceden un privilegio muy acotado, mientras que otras, como CAP_SYS_ADMIN, abarcan tantas operaciones que equivalen en la práctica a ser root. Por eso lo importante no es memorizar la lista, sino saber consultar qué capacidad tiene un binario y valorar si el privilegio que otorga es proporcionado a su función.

Las búsquedas de la columna de auditoría utilizan las siguientes opciones de find:

Los sistemas de archivos ext4, XFS y Btrfs admiten ACL sin opciones de montaje adicionales. El soporte reside en el núcleo y en el sistema de archivos, y las ACL se almacenan como atributos extendidos del inodo, de modo que un archivo puede tener ACL aunque las órdenes getfacl y setfacl no estén disponibles.

Un archivo con ACL se identifica por el signo + tras los permisos:

getfacl, del inglés get file access control list, muestra la ACL completa de un archivo o directorio. Es la orden que revela los permisos reales cuando ls -l marca un +, ya que, como se explicó en la sección 5.1, la tripleta del grupo de ls -l muestra entonces la máscara y no los permisos efectivos de cada entrada. No modifica nada, solo consulta.

Cada entrada sigue el formato tipo:calificador:permisos de la sección 5.3. Las entradas con el calificador vacío, user::, group:: y other::, son las tres clases del modo tradicional, mientras que lo que añade la ACL son las entradas con nombre, como user:maria: o group:auditores:.

Algunas opciones de uso frecuente son las siguientes:

setfacl, del inglés set file access control list, es la orden complementaria de getfacl. Añade, modifica o elimina entradas en la ACL de un archivo o directorio. Cuando se crea la primera entrada con nombre, el archivo pasa a mostrar el + de ls -l y el núcleo empieza a evaluarlo según el algoritmo de la sección 5.2.1.

Las operaciones se controlan con tres opciones básicas:

Las entradas de usuario y de grupo se indican con el formato tipo:calificador:permisos que se detalla más abajo.

Cada entrada sigue el formato tipo:calificador:permisos:

Con -x solo se indican el tipo y el calificador, sin permisos.

Una ACL por defecto, definida con la opción -d, no controla el acceso al directorio, sino que actúa como plantilla para los archivos y subdirectorios que se creen en él:

La X mayúscula es la ejecución condicional que se explicó en la sección 2.1.2. En la plantilla concede el permiso de ejecución solo a los subdirectorios y a los archivos que ya sean ejecutables, pero no a los archivos de datos normales, evitando marcarlos como ejecutables de forma indebida.

No todas las herramientas conservan las ACL. cp -a, rsync -A y tar --acls las preservan, pero un cp sin opciones o una copia a un sistema de archivos sin soporte las pierde:

Antes de cambios masivos conviene guardar una copia restaurable:

Sin -p, getfacl guarda rutas relativas y setfacl --restore las interpretaría respecto al directorio actual, por lo que la restauración solo funcionaría desde /.

La e indica que el archivo usa extents, el formato de asignación de bloques de ext4, y no tiene relevancia para la seguridad.

El atributo inmutable también lo utilizan los atacantes. Es habitual que el malware de minería o las botnets marquen como inmutables sus tareas de cron, su archivo authorized_keys o sus binarios para dificultar la limpieza, una variante de la técnica T1222.002 de MITRE ATT&CK. Por ello, en la respuesta ante incidentes es necesario buscar archivos con atributos inesperados:

La expresión regular de grep selecciona las líneas cuyo primer campo, el de los atributos, contiene una i o una a:

El CIS Benchmark recomienda ubicar /tmp, /var/tmp, /dev/shm y /home en sistemas de archivos independientes con las siguientes opciones:

Ejemplo en /etc/fstab:

Las opciones se aplican sin reiniciar remontando el sistema de archivos, y se verifican con findmnt:

El operador || ejecuta el echo solo cuando findmnt falla.

findmnt solo admite un punto de montaje por invocación. Con varias rutas interpreta las dos primeras como origen y destino y no muestra nada, por lo que se recorre la lista con un bucle. Si una ruta no es un punto de montaje independiente, como ocurre con /tmp o /home en una instalación con una sola partición, findmnt no devuelve nada y no es posible aplicarle opciones propias.

En la verificación de las ACL, getfacl -s omite los archivos que solo tienen los permisos básicos, de modo que la salida contiene únicamente los que tienen una ACL extendida. Las opciones -nouser y -nogroup de find se explican en la lista de verificación siguiente.

Ejecutar chmod u-s sobre un binario del sistema no es una medida duradera. La siguiente actualización del paquete restaurará el bit. En Debian y Ubuntu, la retirada debe registrarse con dpkg-statoverride, que hace que dpkg respete el modo indicado en futuras actualizaciones:

Antes de retirar el bit, compruebe con dpkg -S a qué paquete pertenece el binario y documente el motivo, ya que algunas funciones, como su, passwd o sudo, dejarán de estar disponibles para los usuarios sin privilegios.

Las comprobaciones anteriores deben ejecutarse periódicamente. El siguiente script compara el inventario actual de binarios privilegiados con una línea base y registra cualquier diferencia en el diario del sistema:

Las órdenes y parámetros del script tienen la siguiente función:

El nombre del archivo no lleva extensión porque run-parts, que ejecuta los scripts de /etc/cron.daily, ignora los nombres que contienen un punto.

La línea base debe regenerarse de forma controlada tras cada actualización que añada binarios privilegiados legítimos, y conviene conservar una copia fuera del sistema auditado, ya que un atacante con privilegios de root podría modificarla.

Todo análisis de permisos empieza por leer correctamente los metadatos de los inodos.

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Este ejercicio consolida el uso de las ACL de la sección 5. Trabaje dentro del directorio /srv/lab_permisos creado en el Ejercicio 1 y utilice la cuenta usuario_lab, que puede atravesar ese directorio pero no es propietaria ni miembro del grupo de los archivos que usted cree en él.

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Realice los siguientes pasos:

Para terminar, revierta los cambios realizados durante la práctica.

Realice los siguientes pasos:

Con la realización de estos ejercicios se consolidan los procedimientos esenciales de configuración, auditoría y corrección de permisos, máscaras, bits especiales, capacidades, listas de control de acceso, atributos de inodo y opciones de montaje en sistemas Linux, conforme a las directrices del CIS Benchmark.