Llevamos cinco lecciones viendo lo mismo en cada ls -l y en cada stat sin explicarlo: -rw-r-----, Uid: (990/meteora), Acceso: (0640/-rw-r-----). Hemos protegido 2026-08-31.dat del corte de luz con el diario, del fallo de un disco con RAID 1 y de un bit volteado con un CRC por registro. Pero no hemos respondido a la pregunta más básica de todas: ¿quién puede leer ese fichero, y quién puede borrarlo?

La respuesta es un modelo de doce bits diseñado en 1971 que sigue siendo, cincuenta años después, la base del control de acceso de todos los sistemas UNIX. Su virtud es la simplicidad; su peligro, que esa simplicidad esconde comportamientos que sorprenden. Que los permisos de un directorio signifiquen cosas distintas de los de un fichero. Que se pueda borrar un fichero que no se puede leer. Que el permiso se compruebe en todos los directorios de la ruta, no solo en el fichero final. Y que un programa ejecutado por un usuario normal pueda, mediante un solo bit, modificar /etc/shadow.

Esta lección explica los doce bits uno a uno, con el porqué de cada comportamiento; añade las ACL POSIX para los casos que los doce bits no cubren; presenta los atributos de fichero, que protegen incluso de root; compara el modelo con el de Windows; y termina fijando y justificando los permisos exactos de todos los ficheros de Meteora, con los comandos completos y una auditoría de lo que suele estar mal.

1. El modelo clásico: usuario, grupo y otros
2. Los bits r, w y x en ficheros y en directorios
3. Notación simbólica y octal: chmod, chown, chgrp
4. umask: cómo se calcula el permiso final
5. Los bits especiales: setuid, setgid y sticky
6. Cómo comprueba el núcleo un acceso, paso a paso
7. Listas de control de acceso POSIX
8. Atributos extendidos y atributos de fichero
9. Comparación con el modelo de Windows
10. Los permisos de Meteora, justificados
11. Errores graves y cómo auditarlos
12. Cierre del módulo 4

Cada fichero tiene en su inodo (04-01) dos identificadores numéricos y doce bits de modo:

• UID del propietario: quién es su dueño. En Meteora, 990 (meteora).
• GID del grupo propietario: qué grupo tiene acceso especial. También 990.
• Modo: doce bits que dicen qué puede hacer cada clase de usuario.

El inodo guarda números, no nombres. La traducción a meteora la hacen ls y stat consultando /etc/passwd y /etc/group; si borras la entrada del usuario, ls -l mostrará 990 a secas y el fichero seguirá siendo suyo.

Ante cualquier acceso, el núcleo clasifica al solicitante en exactamente una de tres clases:

Y ahí está la primera sutileza, que produce un desconcierto clásico:

Las tres clases son excluyentes y se evalúan en ese orden. Si eres el propietario, se aplican solo los bits de usuario, aunque los de grupo sean más permisivos.

El dueño no puede leer su propio fichero, mientras que cualquier otro miembro del grupo meteora sí. No es un fallo: la clase se decide primero y los permisos se aplican después. El dueño, eso sí, siempre puede ejecutar chmod sobre él y arreglarlo.

Cada clase tiene tres bits, r, w y x, lo que da los nueve bits que muestra ls -l, más tres bits especiales que veremos en el apartado 5.

Aquí está el corazón de la lección, y lo que más errores causa: los tres bits significan cosas distintas según el tipo.

Recuerda 04-02: un directorio es un fichero cuyo contenido es la lista de pares (nombre, inodo). Con eso, los tres significados dejan de ser arbitrarios y se vuelven inevitables:

• r = leer el contenido del directorio = leer la lista de nombres. Eso es exactamente lo que hace ls.
• w = escribir en el contenido del directorio = añadir o quitar entradas. Crear un fichero es añadir una entrada; borrarlo es quitarla. Ambas son escrituras en el directorio, no en el fichero.
• x = usar el directorio para llegar a algo = poder resolver un componente de la ruta (04-02) y consultar el inodo asociado a un nombre que ya conoces.

De ahí salen las cuatro consecuencias que hay que interiorizar.

1. x sin r: puedes entrar pero no mirar. Es el "directorio oscuro":

Cualquiera puede acceder a /home/analista/informe.pdf si sabe el nombre exacto, pero ls /home/analista falla con "Permiso denegado". Es la configuración clásica de los directorios personales en servidores compartidos y de la raíz de un servidor web: se sirve lo que se pide, no se enumera el contenido.

2. r sin x: puedes ver los nombres pero nada más. ls datos/ lista a.txt, pero ls -l datos/ falla en cada entrada —porque leer el inodo de cada fichero exige atravesar el directorio— y muestra una línea de interrogantes, -????????? ? ? ? ? a.txt. Esos interrogantes son la firma inconfundible de r sin x, una combinación inútil que casi siempre es un error.

3. Se puede borrar un fichero que no se puede leer ni escribir. Este es el comportamiento que más sorprende, y ahora es evidente:

Borrar no toca el fichero. unlink (04-02) elimina una entrada del directorio y decrementa el contador de enlaces del inodo. La operación es una escritura en el directorio, y por eso el permiso que se comprueba es w en el directorio, no en el fichero. Los permisos del fichero son completamente irrelevantes.

Es la razón por la que existe el bit pegajoso, y por la que un directorio escribible por todos sin ese bit es una bomba.

4. Cambiar el contenido de un fichero no requiere permiso en el directorio, y al revés. Los dos permisos son independientes y protegen cosas distintas: el del fichero protege su contenido, el del directorio protege su nombre.

Los nueve bits se expresan de dos formas equivalentes. En octal, cada dígito codifica tres bits sumando 4 (leer) + 2 (escribir) + 1 (ejecutar/atravesar): así, 6 es rw-, 5 es r-x y 7 es rwx. Los valores más habituales, con su uso correcto:

Los comandos:

Tres precisiones que evitan destrozos. El octal es absoluto y el simbólico es relativo: chmod 640 pone exactamente esos bits, mientras que chmod g+r añade uno sin tocar los demás; en un chmod -R sobre un árbol, el octal es peligroso porque aplica lo mismo a ficheros y a directorios. La X mayúscula es la solución a ese problema, porque significa "ejecutar/atravesar solo si es un directorio o si ya tenía algún x": chmod -R u=rwX,g=rX,o= deja los directorios navegables sin convertir en ejecutables los ficheros de datos. Y solo el propietario y root pueden ejecutar chmod, mientras que solo root puede ejecutar chown para regalar un fichero a otro usuario: si un usuario normal pudiera, esquivaría las cuotas de disco y podría plantar ficheros comprometedores en la cuenta de otro.

Cuando un programa crea un fichero, pasa un modo a open() (04-04) —típicamente 0666— o a mkdir —típicamente 0777—. Pero el fichero no acaba con esos permisos, porque el núcleo aplica una máscara del proceso: la umask.

Permisos finales = modo solicitado AND (NOT umask)

En la práctica, es más fácil verlo como una resta de bits: la umask dice qué permisos quitar.

Fíjate en el detalle importante: la umask nunca añade el bit de ejecución. Los programas piden 0666 para ficheros regulares precisamente para que un fichero de datos jamás nazca ejecutable, por muy permisiva que sea la umask. El x de un programa lo pone después el compilador o el instalador con un chmod explícito.

Los valores habituales y lo que producen:

Meteora usa umask 027, y eso explica todos los -rw-r----- y drwxr-x--- que llevamos viendo desde 04-01. La justificación es exacta: el ingestor crea 2026-09-01.dat y necesita que el agregador y meteo-api —miembros del grupo meteora— puedan leerlo, pero que ningún otro usuario del sistema tenga acceso. 027 da precisamente eso, sin un solo chmod posterior.

Advertencia importante: la umask por defecto es 022, que deja los ficheros legibles por todo el mundo; con ella, 2026-09-01.dat nacería 644 y cualquier usuario del servidor podría leer los datos. La umask de un servicio se fija con UMask=0027 en su unidad de systemd (módulo 7), no en el .bashrc, porque un demonio no lee perfiles de shell. Y se hereda en el fork (02-01), así que un script que la ponga a 000 "para que no haya problemas" está creando ficheros 666 y directorios 777 sin que nadie se dé cuenta.

Los doce bits de modo son nueve de permisos más tres especiales, que en octal forman un cuarto dígito delante:

Si el bit x correspondiente no está puesto, la letra aparece en mayúscula (S, T), y eso casi siempre indica un error: un setuid sin ejecución no sirve para nada.

El problema es concreto. Un usuario normal debe poder cambiar su contraseña, que está en /etc/shadow:

Solo root escribe ahí. ¿Cómo puede entonces un usuario cualquiera modificarlo? La respuesta es el bit setuid:

El recorrido completo, paso a paso:

1. El usuario joan (UID 1000) ejecuta /usr/bin/passwd; fork crea un hijo con UID real 1000 y UID efectivo 1000.
2. execve carga el binario y ve el bit setuid. Entonces hace lo decisivo: pone el UID efectivo al del propietario del fichero, que es root (0).
3. El proceso corre ahora con UID real 1000 (quién lo lanzó) y UID efectivo 0 (con qué privilegios actúa). El núcleo comprueba los permisos con el efectivo.
4. passwd puede abrir /etc/shadow para escritura. Pero antes verifica cuidadosamente la identidad: consulta el UID real para saber quién es de verdad, pide la contraseña actual, y solo permite cambiar esa línea.
5. Al terminar, el proceso muere y el privilegio desaparece con él.

Por qué es peligroso. Un binario setuid root es un programa que cualquiera puede ejecutar con privilegios de root, así que cualquier fallo en él es una escalada de privilegios completa: un desbordamiento de búfer, una inyección de comandos, una variable de entorno mal validada, un fichero temporal con TOCTOU (04-04), o simplemente una opción que permita ejecutar un programa arbitrario. La historia de la seguridad en UNIX está llena de vulnerabilidades en binarios setuid, y por eso la regla es tajante:

Cuanto menos setuid, mejor. Cada binario setuid root del sistema es una superficie de ataque, y hay que poder justificar cada uno.

Dos matices que conviene conocer. El setuid se ignora en los scripts: Linux no lo respeta en ficheros con #!, porque la ventana entre abrir el script y ejecutar el intérprete permitía sustituirlo —un TOCTOU—. Y nosuid al montar (04-03) hace que el núcleo ignore el bit en todo un volumen, que es la razón de montar así los volúmenes de datos.

En un fichero ejecutable, setgid es el análogo de setuid con el grupo: el GID efectivo pasa a ser el del fichero. Se usa para dar acceso a un recurso de grupo sin dar root; /usr/bin/wall, por ejemplo, es setgid tty.

En un directorio hace algo completamente distinto y muy útil:

Un directorio con setgid hace que todo lo que se cree dentro herede su grupo, en lugar del grupo primario de quien lo crea. Y los subdirectorios heredan también el propio bit setgid, así que la propiedad se propaga por todo el árbol.

Sin setgid, si el usuario analista (grupo primario analista) crea un fichero en /var/lib/meteora/, ese fichero será del grupo analista y el agregador —que es del grupo meteora— no podrá leerlo. Con setgid:

Ahora cualquier fichero creado ahí dentro pertenecerá al grupo meteora, lo cree quien lo cree. Es el mecanismo estándar para directorios compartidos por un equipo, y garantiza la coherencia de grupos sin depender de la disciplina de cada usuario.

Recuerda la consecuencia 3 del apartado 2: w en un directorio permite borrar cualquier entrada, sean cuales sean los permisos del fichero. Ahora aplícalo a /tmp, que por definición debe ser escribible por todos:

Sin la t, cualquier usuario podría borrar los ficheros temporales de cualquier otro, o peor: borrar el fichero de sesión de un servicio y sustituirlo por uno propio, que es una vía directa a la suplantación.

El bit pegajoso (sticky bit) añade una restricción a los directorios:

En un directorio con sticky, solo pueden borrar o renombrar una entrada: el propietario del fichero, el propietario del directorio, o root. El permiso w del directorio deja de bastar.

Se aplica a todo directorio escribible por varios usuarios: /tmp, /var/tmp, /dev/shm y cualquier zona de intercambio compartida. Y hay que saber una cosa más: el sticky bit en ficheros no hace nada en Linux moderno. Antiguamente indicaba "mantén este ejecutable en swap"; hoy se ignora.

Cuando meteo-api ejecuta open("/var/lib/meteora/lecturas/2026-08-31.dat", O_RDONLY), el núcleo hace esto:

Los cinco puntos que hay que retener de este diagrama:

1. El permiso x se comprueba en TODOS los directorios de la ruta. Es lo que hace la resolución de rutas de 04-02, componente a componente. Si a /var/lib/meteora le falta el x para tu clase, no importa que el fichero final sea rw-rw-rw-: no llegas. Es la fuente número uno de los "Permiso denegado" incomprensibles, y se diagnostica en un segundo con namei -l, que muestra los permisos de cada componente:

Cuando alguien no puede acceder a un fichero, este es el primer comando que hay que ejecutar.

2. Las clases son excluyentes y el orden es fijo. Propietario, luego grupo, luego otros: la primera coincidencia decide y no se mira más. De ahí el fichero ----r--r-- que el dueño no puede leer.

3. Cuentan todos los grupos suplementarios. Un usuario pertenece a un grupo primario y a varios secundarios (id los muestra todos), y cualquiera sirve para entrar en la clase de grupo. Aviso importante: los grupos se leen al iniciar sesión, así que un usermod -aG no afecta a las sesiones abiertas ni a los servicios ya arrancados.

4. Root se salta casi todo. El UID efectivo 0 concede casi cualquier acceso, con dos excepciones notables: no puede ejecutar un fichero sin ningún bit x, y no puede escribir en un fichero inmutable (apartado 8).

5. Se comprueba en open(), no en read(). Los permisos se verifican una sola vez, al abrir. Si después alguien ejecuta chmod 000, el proceso que ya lo tiene abierto sigue leyendo sin problemas, porque su descriptor apunta a la entrada de la tabla de ficheros abiertos (04-04) y no al nombre ni al modo. Para cortar el acceso hay que hacer que cierre el descriptor.

El modelo de tres clases tiene un límite estructural: solo permite expresar permisos para un usuario, un grupo y el resto. Un caso real de Meteora lo desborda enseguida: hay que dar acceso de solo lectura a /var/lib/meteora/lecturas a la usuaria nuria, del equipo de análisis, sin meterla en el grupo meteora —que le daría acceso a todo lo demás del servicio, incluida la configuración— y sin abrir los permisos de "otros".

Con los nueve bits no se puede. Con ACL POSIX, sí:

El resultado:

Los elementos: user::rwx y group::r-x son el propietario y el grupo propietario, equivalentes a los bits u y g de siempre; user:nuria:r-x y group:analistas:r-- son entradas nombradas, que dan permisos a un usuario o grupo concreto; other::--- son los demás; default:... es lo que heredarán los ficheros creados aquí; y mask::r-x es la máscara, el máximo efectivo de todas las entradas nombradas y del grupo.

La máscara es la parte que confunde a todo el mundo, y merece una explicación clara. Los permisos efectivos de cualquier entrada nombrada son la intersección de esa entrada con la máscara. Si la máscara es r-- y la entrada de nuria es rwx, nuria obtiene solo r--, y getfacl lo señala explícitamente:

Existe porque ls -l solo tiene nueve bits que mostrar. Cuando hay una ACL, los bits de grupo que muestra ls -l son en realidad la máscara, no los permisos del grupo propietario. Es un compromiso deliberado para que las herramientas antiguas vean algo razonable, y de ahí sale la trampa práctica:

Un chmod g-w sobre un fichero con ACL modifica la MÁSCARA, y por tanto recorta de golpe los permisos efectivos de todas las entradas nombradas. Es la forma más habitual de romper una ACL sin querer.

La regla es: cuando un fichero tiene + en ls -l, gestiona sus permisos con setfacl, no con chmod.

Comandos esenciales:

Dos advertencias operativas: las ACL requieren que el sistema de archivos las soporte —ext4 y XFS sí, y en las distribuciones actuales están activadas por defecto—; y hay que verificar que las herramientas de copia las preserven, porque cp -a, rsync -A y tar --acls sí lo hacen pero un cp normal las pierde en silencio, lo que produce fallos de permisos misteriosos tras una restauración.

Además de los permisos, un inodo puede llevar dos cosas más.

Atributos extendidos (xattr): pares clave-valor arbitrarios organizados en cuatro espacios de nombres —system.* para las ACL y el uso interno del núcleo, security.* para las etiquetas de SELinux y las capabilities, trusted.* para uso privilegiado, y user.* para metadatos de aplicación, escribible por cualquiera con permiso w—. Se manipulan con setfattr -n user.origen -v "estacion-42" fichero y getfattr -d fichero. Las ACL del apartado anterior son atributos extendidos (system.posix_acl_access), igual que las etiquetas de SELinux y AppArmor del módulo 5.

Atributos de fichero (chattr): banderas en el inodo que modifican el comportamiento del sistema de archivos. Son mucho más potentes de lo que parecen, porque algunos vinculan incluso a root:

Los dos primeros son los interesantes:

+a es especialmente valioso para los registros de seguridad, porque un atacante que consiga root no puede borrar sus huellas del log: solo puede seguir añadiendo. Es un complemento natural del O_APPEND de 04-04, con la diferencia de que aquel es un acuerdo del programa y este lo impone el sistema de archivos.

Ahora la letra pequeña, para no crear falsa seguridad. Quitar el atributo requiere la capacidad CAP_LINUX_IMMUTABLE, que root tiene: chattr -i lo desactiva en un segundo, y un atacante con root puede hacerlo. Su valor real es doble: evita errores propios —un rm -rf mal escrito, un script de despliegue defectuoso— y obliga a un paso deliberado y auditable antes de tocar algo crítico. No es una barrera contra un atacante decidido; es un seguro contra accidentes y una traza en los registros, porque el aislamiento fuerte frente a root es cosa de capabilities, SELinux y AppArmor, que se ven en el módulo 5. Y una consecuencia práctica que muerde a todo el mundo: un fichero con +i rompe las actualizaciones automáticas del gestor de paquetes, de forma confusa. Documenta siempre qué has marcado.

Conviene conocer el otro modelo, porque los conceptos se cruzan constantemente en entornos mixtos:

La diferencia más importante para quien viene de Windows es la semántica del borrado: allí se controla con un permiso del fichero, aquí con el permiso w del directorio. Es la causa de la mayoría de las sorpresas al migrar, y explica por qué el bit pegajoso es necesario en UNIX y no tiene equivalente directo en Windows. La otra es la denegación explícita: en Windows puedes decir "todos los del grupo Ventas pueden leer, excepto Juan", mientras que en UNIX solo se conceden permisos y la única forma de excluir a alguien es no incluirlo en ninguna clase que los tenga.

El juicio equilibrado: el modelo de Windows es más expresivo y el de UNIX más comprensible. Y en seguridad, lo comprensible tiene un valor propio: una ACL de Windows con veinte entradas heredadas, denegaciones y grupos anidados puede ser tan difícil de auditar que nadie sepa realmente quién tiene acceso. Los nueve bits de UNIX se leen de un vistazo.

Ahora, la aplicación completa. Estos son los permisos exactos de todo lo que compone el servicio, con el porqué de cada decisión.

Los comandos completos:

Las cuatro decisiones que de verdad importan aquí, porque son las que la gente hace mal:

1. La configuración pertenece a root, no al servicio. Es la aplicación directa del principio de mínimo privilegio: si meteora fuera el dueño de meteora.conf, un atacante que comprometiera meteo-api podría reescribir la configuración —cambiar rutas, desactivar la validación, apuntar a otro servidor— y esperar al reinicio. Siendo de root con grupo meteora y modo 640, el servicio lee pero no escribe. Lo mismo con el binario: meteora no puede sustituir /usr/bin/meteo-api por un troyano.

2. Los secretos van en un fichero aparte. No porque 640 no baste, sino porque separa dos ciclos de vida: meteora.conf se puede versionar en Git, compartir en una incidencia y copiar entre entornos; secrets.conf no. Mezclarlos garantiza que las claves acabarán en un repositorio o en un ticket. Se usa 0640 con grupo meteora —y no 0600— porque el servicio necesita leerlo al arrancar.

3. Los logs tienen grupo adm, no meteora. Así los administradores y la monitorización leen los registros sin pertenecer al grupo del servicio, que les daría acceso también a los datos y a la configuración. Es separación de privilegios, no burocracia.

4. Ningún binario setuid. meteo-api escucha en el puerto 8080 y no en el 80, precisamente para no necesitar privilegios. Si tuviera que usar un puerto por debajo de 1024, la solución correcta no es setuid root, sino AmbientCapabilities=CAP_NET_BIND_SERVICE en la unidad de systemd, o un proxy inverso delante. Volveremos sobre las capabilities en el módulo 5.

Los cuatro errores que más daño hacen, y el comando que los encuentra.

chmod 777. Es el error emblemático. Significa "cualquier usuario del sistema puede leer, modificar y borrar esto", y además marca los ficheros como ejecutables. Se pone casi siempre para salir del paso ante un "permiso denegado" que no se ha entendido, y deja el agujero abierto para siempre.

-perm -0002 busca el bit de escritura para "otros". Los únicos resultados legítimos son directorios con sticky bit (/tmp, /var/tmp, /dev/shm); todo lo demás hay que revisarlo. Ante un "permiso denegado", el reflejo correcto es namei -l, no chmod 777.

Secretos legibles por todos. Una clave privada con permiso de lectura para "otros" es una clave comprometida; de hecho, ssh se niega a usar una clave demasiado abierta, precisamente por esto.

chmod -R sobre un árbol mixto. Este merece explicación porque parece inofensivo:

El segundo es el caso instructivo. Aplica 644 a todo, incluidos los directorios, que se quedan sin el bit x: nadie puede atravesarlos, y todo el árbol se vuelve inaccesible —el efecto "interrogantes" del apartado 2—. La forma correcta usa la X mayúscula o separa por tipo:

Binarios setuid innecesarios. El inventario hay que revisarlo y justificarlo entrada por entrada. Una lista saneada tiene entre 10 y 20: passwd, su, sudo, mount, umount, ping, chsh, newgrp... Cualquier binario setuid en /home, /tmp, /var o en un directorio de aplicación es una alarma roja, y probablemente una puerta trasera. Guardar una lista de referencia y compararla es una detección barata y eficaz:

Otras dos comprobaciones que conviene automatizar son find / -xdev \\( -nouser -o -nogroup \\) y find / -xdev -type f -perm -0002 -perm -0111. Los ficheros huérfanos —cuyo UID no corresponde a ningún usuario— aparecen tras borrar una cuenta y son peligrosos porque el siguiente usuario que reciba ese UID heredará su propiedad. Y un fichero a la vez escribible por todos y ejecutable es un vector de ataque de manual: cualquiera sustituye su contenido y espera a que alguien lo ejecute.

Responder a un "permiso denegado" con chmod 777. Casi siempre el problema es un x que falta en un directorio de la ruta. Ejecuta namei -l primero: te dirá en qué componente exacto se rompe.

Aplicar chmod -R con un valor octal. Trata igual a ficheros y directorios, y deja los directorios sin x o los ficheros con x. Usa u=rwX,g=rX,o= o separa con find -type d y find -type f.

Creer que quitar r y w a un fichero impide borrarlo. Borrar depende del permiso w en el directorio. Si quieres proteger un fichero de verdad, protege el directorio o usa chattr +i.

Olvidar que los grupos se leen al iniciar sesión. Tras un usermod -aG, ni tu sesión abierta ni los servicios en marcha ven el grupo nuevo. Reinicia la sesión o el servicio.

Usar chmod sobre un fichero con ACL. Modifica la máscara y recorta los permisos efectivos de todas las entradas nombradas: si ves un + en ls -l, usa setfacl. Y al copiar, preserva las ACL con cp -a, rsync -A o tar --acls, porque un cp a secas las pierde en silencio.

Dejar que un servicio sea dueño de su configuración y de su binario. Si lo comprometen, puede reescribir ambos y persistir. Configuración y binario, de root; el servicio solo lee.

Poner setuid a un programa propio "para que funcione". Un binario setuid root es una escalada de privilegios esperando a un fallo. Casi siempre hay una alternativa: una capability concreta, un grupo, un socket con permisos, o un servicio separado.

Consejo: namei -l y getfacl son tus dos herramientas de diagnóstico —la primera recorre la ruta componente a componente, la segunda revela las ACL que ls -l solo insinúa con un +— y audita periódicamente contra una línea base: la lista de setuid, los escribibles por todos y los huérfanos detectan tanto errores propios como intrusiones.

Crea una estructura de pruebas y demuestra empíricamente, mostrando la salida de cada comando: (a) que con x pero sin r en un directorio puedes leer un fichero cuyo nombre conoces pero no listarlo; (b) que con r pero sin x obtienes los interrogantes de ls -l; (c) que puedes borrar un fichero de otro usuario, sin permiso de lectura sobre él, si tienes w en el directorio; (d) que al activar el bit pegajoso ya no puedes. Explica en cada caso qué permiso se comprueba y sobre qué objeto.

La usuaria nuria necesita leer todos los ficheros de /var/lib/meteora/lecturas, incluidos los que se creen en el futuro, sin pertenecer al grupo meteora y sin que los permisos de "otros" cambien. Implementa la solución completa con ACL, verifica que funciona, comprueba qué ocurre después con un chmod g-w sobre el directorio y explica por qué. Compara con las dos alternativas malas —meterla en el grupo meteora, o poner o+r— indicando exactamente a qué tendría acceso de más en cada caso.

Escribe un script de auditoría que revise: binarios setuid y setgid comparados con una lista de referencia; ficheros y directorios escribibles por todos que no tengan sticky bit; secretos en /etc legibles por otros; ficheros huérfanos; y ficheros simultáneamente escribibles por todos y ejecutables. Para cada hallazgo debe indicar el riesgo concreto y la corrección propuesta. Ejecútalo en tu máquina e interpreta los resultados: di cuáles son legítimos y por qué.

Solución 1

(a) x sin r — el directorio oscuro:

ls necesita r para leer la lista de nombres del directorio, y no lo tiene. cat solo necesita x para atravesarlo hasta el inodo de un nombre que ya conoce. Se comprueba r sobre el directorio en el primer caso y x sobre el directorio más r sobre el fichero en el segundo.

(b) r sin x:

ls lee la lista y funciona. ls -l necesita atravesar el directorio para leer el inodo de cada entrada, y sin x no puede: de ahí los interrogantes. cat falla por la misma razón.

(c) Borrar sin poder leer, y (d) con sticky bit:

En (c), nobody no puede leer un fichero de root con modo 600 pero sí puede borrarlo, porque unlink es una escritura en el directorio y tiene w ahí: los permisos y el propietario del fichero no intervienen en absoluto.

En (d), con sticky, solo el dueño del fichero (root), el dueño del directorio o root pueden borrar. Fíjate en el detalle: el error ya no es EACCES ("Permiso denegado") sino EPERM ("Operación no permitida"), porque la comprobación que falla no es la del bit w sino la regla adicional del sticky. Es exactamente el mecanismo que protege /tmp.

Solución 2

El paso 3 es el que más se olvida: sin la ACL por defecto, nuria leería los ficheros de hoy pero no los de mañana, y el fallo aparecería una semana después sin causa aparente.

Qué ocurre con chmod g-w:

chmod sobre un fichero con ACL modifica la máscara. Si el chmod recortara los bits r o x de la clase de grupo, la máscara bajaría y los permisos efectivos de nuria se recortarían con ella, aunque su entrada siga diciendo r-x. Se restaura con setfacl -m m::rx. La regla operativa: cuando ls -l muestra +, gestiona los permisos con setfacl.

Las dos alternativas malas:

La ACL da exactamente el acceso pedido, a la persona pedida, sobre los ficheros pedidos, y queda documentado en getfacl: es el principio de mínimo privilegio aplicado con la herramienta adecuada.

Solución 3

Interpretación de los resultados en una máquina sana. En [1] aparecen entre 10 y 20 binarios, todos en /usr/bin, /usr/sbin, /usr/lib o /bin —passwd, su, sudo, mount, umount, chsh, newgrp, pkexec, ping, y setgid crontab, wall, write—, y todos son legítimos porque necesitan privilegios que un usuario normal no tiene: modificar /etc/shadow, montar sistemas de archivos, abrir sockets ICMP. Un setuid fuera de esos directorios —en /home, /tmp, /opt o /var— es una alarma roja.

En [2] lo esperable es ningún resultado, porque /tmp, /var/tmp y /dev/shm quedan excluidos por el filtro ! -perm -1000; si aparece algo, casi siempre es un chmod 777 histórico. En [3] debe estar vacío, y cualquier resultado exige dos acciones y no una: corregir el permiso y rotar la credencial, porque hay que asumir que ha sido leída. En [4] suele haber alguno tras desinstalar software o borrar cuentas, y se corrige con chown o borrando el fichero. Y [5] debe estar vacío siempre: es la combinación más peligrosa de todas.

Lo que convierte esto en una herramienta útil es ejecutarlo periódicamente y comparar con la ejecución anterior: los hallazgos nuevos, y no la lista completa, son lo que hay que mirar. Automatizar estas comprobaciones e integrarlas con la auditoría del sistema es el tema de Auditoría, Registros y Respuesta a Incidentes.

El modelo de permisos de UNIX son doce bits y dos números en el inodo, con tres clases —usuario, grupo y otros— que son excluyentes y se evalúan en ese orden, de ahí que un fichero ----r--r-- no lo pueda leer su propio dueño. Los bits r, w y x significan cosas distintas en ficheros y en directorios, y esa diferencia deja de ser arbitraria en cuanto recuerdas que un directorio es un fichero con una lista de pares (nombre, inodo): r es leer esa lista, w es añadir o quitar entradas y x es atravesar. De ahí las cuatro consecuencias: el directorio oscuro 0711, los interrogantes de r sin x, y sobre todo que se puede borrar un fichero que no se puede leer, porque unlink escribe en el directorio y no toca el fichero. Esa última es la razón de que exista el bit pegajoso, sin el cual /tmp sería inutilizable.

Los permisos se expresan en octal o simbólico, y la diferencia importa: el octal es absoluto y el simbólico relativo, así que un chmod -R 644 deja los directorios sin x y rompe el árbol entero. La forma correcta de recorrer un árbol mixto es la X mayúscula o separar con find -type d y -type f. La umask decide con qué permisos nacen los ficheros restando bits del modo solicitado —666 para ficheros, 777 para directorios—, y nunca añade el x: la 027 de Meteora es exactamente lo que produce los 0640 y 0750 que llevamos viendo todo el módulo, frente a la 022 por defecto que los dejaría legibles por todo el sistema.

Los tres bits especiales resuelven tres problemas concretos. setuid explica cómo passwd escribe en /etc/shadow: execve pone el UID efectivo al del propietario del binario, dejando el UID real para saber quién es de verdad; es potentísimo y por eso peligroso, y nosuid al montar (04-03) lo desactiva por volumen. setgid en un directorio hace que todo lo que se cree dentro herede su grupo y propaga el propio bit a los subdirectorios, que es lo que garantiza la coherencia de grupo en /var/lib/meteora. Y el sticky limita el borrado al dueño del fichero.

La comprobación del núcleo tiene cinco propiedades que hay que recordar: el x se exige en todos los directorios de la ruta —namei -l es el diagnóstico—, las clases son excluyentes, cuentan todos los grupos suplementarios pero solo los que había al iniciar sesión, root se salta casi todo salvo la ejecución sin ningún x y el atributo inmutable, y se comprueba en open(), de modo que un chmod 000 no corta a quien ya tiene el fichero abierto. Cuando las tres clases no bastan, las ACL POSIX dan permisos a usuarios y grupos concretos, con ACL por defecto para la herencia y una máscara que actúa de techo —y que un chmod descuidado recorta, rompiendo la ACL sin avisar—. Los atributos chattr +i y +a añaden una capa que vincula incluso a root: la primera evita accidentes sobre ficheros críticos y la segunda hace un log al que solo se puede añadir. Frente al modelo de Windows, más expresivo con sus ACE, su herencia nativa y sus denegaciones explícitas, el de UNIX gana en algo que en seguridad vale mucho: se lee de un vistazo.

Aplicado a Meteora, todo se reduce a cuatro decisiones: datos 2750/0640 con meteora:meteora; configuración y binario de root, para que un servicio comprometido no pueda reescribirse a sí mismo; secretos en fichero aparte con +i; logs con grupo adm para separar quien administra de quien ejecuta; y ningún binario setuid. Y las auditorías con find —setuid contra una lista de referencia, escribibles por todos sin sticky, secretos legibles, huérfanos y escribibles-y-ejecutables— convierten esas decisiones en algo verificable en lugar de en una intención.

Merece la pena mirar el recorrido completo, porque el módulo ha tenido un hilo muy claro.

Empezamos con la abstracción (04-01): un fichero es una secuencia de bytes con nombre, tamaño y dueño que el sistema coloca donde quiere, y esa idea resuelve de golpe los siete problemas que tendría cualquier aplicación sobre el vector de bloques crudo del módulo 2, con la misma estrategia que la memoria virtual. Vimos los siete tipos de UNIX, diseccionamos el inodo —y su ausencia más importante, el nombre—, recorrimos la disposición física con superbloque, mapas de bits y tabla de inodos, calculamos el compromiso del tamaño de bloque y elegimos ext4 para /var/lib/meteora con argumentos y no por costumbre.

El nombre, que faltaba, llegó en 04-02: un directorio es un fichero con pares (nombre, inodo), la organización en grafo acíclico explica por qué no se permiten enlaces duros a directorios, la resolución de rutas cuesta once accesos en frío y casi ninguno con la caché de dentries, y unlink quita un nombre en lugar de borrar un fichero, de donde salen los enlaces duros, el fichero borrado que sigue ocupando 17 GB y el truncate -s 0 /proc/<pid>/fd/N que lo cura.

Después ensamblamos el árbol (04-03): particiones GPT, LVM con sus instantáneas para copiar en caliente, y el montaje paso a paso, con UUID= en un fstab validado y las opciones nosuid,nodev,noexec que cierran tres vectores por el precio de tres palabras. Y debajo de todo, el VFS con sus cuatro objetos, que es lo que permite que el mismo open() funcione sobre ext4, sobre tmpfs, sobre /proc —que inventa sus ficheros al leerlos— y sobre NFS.

Con el mapa completo pasamos a usarlo (04-04): cinco llamadas al sistema, las tres tablas que explican fork, dup y 2>&1, las dos capas de búfer que hay que distinguir para no perder datos, y los dos patrones que más vas a escribir —la publicación atómica con temporal y rename(), y O_APPEND para los logs— más flock para que no haya dos agregador. Luego bajamos al disco (04-05): las cuatro estrategias de asignación hasta los extents, los tres mecanismos que hacen que un fichero escrito 24 bytes cada 125 ms acabe contiguo, el diario con su bloque de commit atómico, los tres modos de ext4 con ordered como elección razonada, y la distinción que cierra el asunto: coherencia de metadatos no es integridad de datos, RAID 1 detecta discrepancias pero no sabe cuál copia es la buena, y a veces la garantía tiene que ponerla la aplicación.

Y esta última lección ha respondido a quién puede hacer qué.

Si el módulo 2 respondía a cómo se reparte un recurso escaso y el módulo 3 a cómo se coordinan varios flujos sobre un dato compartido, el módulo 4 ha respondido a cómo se guarda algo para que siga estando mañana. Y la respuesta ha tenido siempre la misma forma: una estructura en el disco, una capa de indirección que la hace manejable, y una disciplina —de formato, de sincronización o de permisos— que el programador debe respetar.

Pero fíjate en dónde nos deja el último apartado. Hemos cerrado el acceso a /var/lib/meteora con nueve bits y una ACL, y hemos supuesto todo el tiempo que el UID 990 es meteora, que quien inicia sesión es quien dice ser, y que un proceso que corre como meteora hace lo que meteora haría. Ninguna de esas tres suposiciones es gratis. ¿Cómo demuestra alguien que es quien dice ser? ¿Por qué root puede saltarse todos los permisos, y hay alguna forma de que no pueda? ¿Qué impide que un meteo-api comprometido, con sus permisos perfectamente configurados, haga cosas que nadie previó? ¿Y cómo se detecta que algo así ha ocurrido, cuando el atacante controla el sistema que escribe los registros?

Los permisos de fichero son solo una pieza de un modelo de protección mucho más amplio, que abarca sujetos, objetos, dominios de protección, autenticación, privilegios mínimos, control de acceso obligatorio y auditoría. Es el Módulo 5: Protección y Seguridad del Sistema, y empieza en Principios de Protección y Control de Acceso.