Permisos en Linux: usuarios, grupos, chmod y umask

Los permisos de Linux deciden quién puede leer, cambiar y ejecutar cada archivo del sistema. La mayoría de los problemas que aparecen en una revisión de seguridad no son exploits sofisticados. Son un archivo de configuración que cualquier cuenta local puede escribir, un script que un servicio root ejecuta pero que un usuario normal puede editar, o un binario con el bit setuid activado que nadie recuerda haber puesto. Este artículo construye el mecanismo desde cero: propietario, grupo, los bits rwx, chmod, umask y los bits especiales que más importan en una revisión. Vas a crear archivos, cambiar sus modos, probar el acceso como un segundo usuario local en una VM de laboratorio y buscar permisos riesgosos.

La idea central es el mínimo privilegio. Un proceso debe tener solo el acceso que necesita, y un archivo solo debe poder escribirlo quien tiene que cambiarlo. Los modos de archivo son el primer lugar donde Linux aplica esa regla, por eso son lo primero que conviene revisar.

#Qué es un permiso de archivo

Cada archivo y cada directorio tiene tres cosas que deciden el acceso:

1. Un propietario, una cuenta de usuario.
2. Un grupo, una cuenta de grupo.
3. Un modo, un conjunto de bits que indica qué pueden hacer el propietario, el grupo y los demás.

Ejecuta esto con cualquier archivo de tu carpeta personal:

ls -l notes.txt

El primer carácter es el tipo de archivo (- es archivo regular, d es directorio, l es enlace simbólico). Los nueve caracteres siguientes son el modo. Los nombres del propietario y del grupo aparecen después del número de enlaces.

El kernel revisa los permisos cada vez que un proceso abre un archivo. Un shell, un servidor web y una tarea de cron pasan por la misma comprobación. Si la comprobación falla, aparece Permission denied. El sistema de archivos no se preocupa por si el proceso es de confianza.

#Propietario, grupo y los demás

El modo tiene tres tercias, una por cada clase de usuario:

• Usuario (u): la cuenta que es dueña del archivo.
• Grupo (g): los miembros del grupo dueño del archivo.
• Otros (o): toda cuenta que no es el propietario ni miembro del grupo.

Linux evalúa las clases en ese orden. Si tu cuenta es la propietaria, se aplican los bits del propietario y se ignoran los de grupo y de otros, aunque dieran más acceso. Esto sorprende a mucha gente. Un archivo cuyos bits de propietario son --- no se abre para su propio dueño, aunque los bits de grupo sean rwx y el dueño pertenezca a ese grupo.

La lista de grupos es aparte. Mira la tuya con:

id
groups

Un cambio en la pertenencia a grupos normalmente se aplica en el siguiente inicio de sesión, no en el shell donde ejecutaste el comando.

#Leer los bits rwx

Cada tercia tiene tres bits:

Dos puntos confunden a quien está empezando.

Primero, el bit x de un directorio es el que permite atravesarlo. Un directorio con r y sin x deja ver los nombres, pero no abrir nada. Un directorio con x y sin r deja abrir un archivo cuyo nombre exacto ya conoces, pero no listar el contenido.

Segundo, el permiso de escritura sobre el archivo no permite borrarlo. Borrar depende de los permisos de escritura y ejecución sobre el directorio que contiene la entrada. Un archivo tuyo dentro de un directorio en el que no puedes escribir sigue sin poder ser eliminado por ti.

#Notación simbólica y octal

chmod acepta dos notaciones para lo mismo.

Octal. Cada tercia se convierte en un dígito, la suma de sus bits: r vale 4, w vale 2, x vale 1. Así, rw- es 6, r-- es 4, r-x es 5 y rwx es 7. El modo 644 significa lectura y escritura para el propietario (6), lectura para el grupo (4) y lectura para los demás (4). El modo 600 significa que solo el propietario lee o escribe.

Simbólica. Indicas la clase, el operador y los bits:

• Clases: u (propietario), g (grupo), o (otros), a (todos). Si no indicas clase, se asume a, excepto que los bits de la umask se dejan intactos.
• Operadores: + añade bits, - los quita, = fija exactamente esos bits en la clase y limpia el resto.

Así, chmod u=rw,go=r notes.txt produce el mismo resultado que chmod 644 notes.txt. chmod g+w notes.txt añade escritura para el grupo y deja los demás bits como estaban.

La octal es compacta y fácil de pegar en scripts. La simbólica es más segura para un cambio puntual, porque no borra bits en los que no pensaste. En una revisión vas a ver ambas, en archivos de gestión de configuración, Dockerfiles y scripts de instalación.

#chmod paso a paso

chmod cambia el modo. En un archivo, solo su propietario o root puede hacerlo con éxito. Cualquier otro recibe Operation not permitted.

Un hábito seguro es leer el modo, cambiarlo y volver a leerlo:

stat -c '%a %A %U:%G %n' notes.txt
chmod 600 notes.txt
stat -c '%a %A %U:%G %n' notes.txt

stat -c muestra el modo en octal (%a), el modo simbólico (%A), los nombres del propietario y del grupo (%U, %G) y el nombre del archivo (%n). Usarás este formato en todo el laboratorio.

chown cambia el propietario y chgrp cambia el grupo. Cambiar el propietario a otro usuario normalmente requiere root. No ejecutes chown -R sobre un árbol sin antes listar qué va a tocar.

#umask: modos por defecto de los archivos nuevos

Cuando un programa crea un archivo, pide un modo inicial. Para un archivo regular el valor inicial es 666. Para un directorio es 777. La umask quita bits de ese valor inicial. La define el shell, y todo archivo y directorio que crean el shell y sus procesos hijos pasa por ella.

La mayoría de las distribuciones de Linux usan 022 por defecto. Para un archivo, 666 menos 022 da 644, así que los archivos nuevos quedan rw-r--r--. Para un directorio, 777 menos 022 da 755, así que los directorios nuevos quedan rwxr-xr-x. La umask solo quita permisos. Un modo nunca termina siendo más permisivo que el valor inicial.

Revisa tu valor:

umask

Una umask más restrictiva, como 077, produce archivos 600 y directorios 700, accesibles solo para el propietario. Una más abierta, como 002, produce archivos 664 y directorios 775, que el grupo puede escribir. Una umask definida en el perfil del shell afecta a ese shell y a sus hijos. No cambia los archivos que ya existen.

#setuid, setgid y el bit sticky

Los modos octales de cuatro dígitos añaden un dígito al frente para tres bits especiales:

• setuid (4000): cuando se ejecuta un programa, corre con el ID del propietario del archivo y no con el de quien lo invoca. Un binario de root con setuid corre como root.
• setgid (2000): en un ejecutable, corre con el ID del grupo del archivo. En un directorio, las entradas nuevas heredan el grupo del directorio.
• sticky (1000): en un directorio, solo el propietario de una entrada o root puede renombrarla o borrarla, aunque todos puedan escribir en el directorio. /tmp es el ejemplo clásico.

ls -l muestra setuid como s en la posición de ejecución del propietario, y sticky como t en la posición de ejecución de otros. En Ubuntu 24.04, la línea de passwd es esta:

-rwsr-xr-x 1 root root 64152 May 30  2024 /usr/bin/passwd

Programas como passwd necesitan setuid porque deben escribir archivos protegidos de cuentas en nombre de un usuario normal. El riesgo es que cada binario setuid de root permite a un usuario normal ejecutar código con privilegios de root. Un fallo en uno, como una corrupción de memoria o una llamada insegura a un programa auxiliar, puede convertirse en una escalada de privilegios local. Los revisores mantienen una lista corta de binarios setuid y la comparan con una línea base conocida. Un archivo setuid nuevo que nadie instaló a propósito es un hallazgo que necesita respuesta.

Los archivos escribibles por todos son el otro problema frecuente. Un archivo con o+w permite que cualquier cuenta local cambie su contenido. Si ese archivo es un script, una configuración que lee un servicio root o un binario en un directorio del PATH, el atacante no necesita un exploit. Solo edita el archivo. Revisa también los directorios. Un directorio escribible en una ruta que ejecuta root puede permitir que un atacante reemplace un archivo aunque el archivo en sí esté bloqueado.

#Laboratorio práctico: archivos y permisos

Ejecuta esto en un entorno Linux que controlas: una distribución de WSL o una VM creada para el curso. No lo ejecutes en un servidor de producción ni en una máquina compartida. La sección del segundo usuario crea una cuenta, así que hazla solo en tu VM de laboratorio.

#Crear e inspeccionar un archivo

mkdir ~/permlab && cd ~/permlab
echo 'lab secret' > notes.txt && ls -l notes.txt

En Ubuntu 24.04 bajo WSL, el archivo nuevo mostró -rw-r--r--, con propietario y grupo con el nombre de la cuenta. Tu nombre de usuario, la fecha y el grupo serán distintos. Compara el modo.

#Cambiar el modo

chmod 600 notes.txt && stat -c '%a %U:%G %n' notes.txt
umask

Salida observada:

600 usurio:usurio notes.txt
0022

El nombre de tu cuenta será distinto. El 600 significa que solo el propietario lee y escribe. El 0022 es la umask del shell actual, y el cero inicial forma parte de la notación octal.

Ahora un directorio:

mkdir sub && chmod 750 sub && stat -c '%a %n' sub

Observado: 750 sub. El propietario tiene acceso total, el grupo puede leer y entrar, y los otros usuarios no reciben nada.

Cambios simbólicos, uno a uno, con una lectura después de cada uno:

chmod u=rw,go=r notes.txt && stat -c '%a %A %n' notes.txt
chmod g+w notes.txt && stat -c '%a %A %n' notes.txt
chmod o-r notes.txt && stat -c '%a %A %n' notes.txt

Salida observada:

644 -rw-r--r-- notes.txt
664 -rw-rw-r-- notes.txt
660 -rw-rw---- notes.txt

Cada comando cambió solo los bits que nombró.

#Ver cómo la umask cambia los archivos nuevos

Ejecuta umask en un subshell para que el cambio no quede en tu sesión:

(umask 077; touch private.txt; stat -c '%a %A %n' private.txt)
(umask 002; touch shared.txt; mkdir made_dir; stat -c '%a %A %n' shared.txt made_dir)

Salida observada:

600 -rw------- private.txt
664 -rw-rw-r-- shared.txt
775 drwxrwxr-x made_dir

Con 077, el archivo perdió todos los bits de grupo y de otros. Con 002, el grupo ganó escritura tanto en el archivo como en el directorio. El directorio partió de 777 y perdió solo 002.

#Probar el acceso como segundo usuario local

Este paso requiere una cuenta que puedas crear en tu propia VM. Ejecútalo solo allí.

sudo useradd -m labuser
sudo -u labuser cat ~/permlab/notes.txt

No ejecuté estos comandos. La cuenta de WSL necesita contraseña para sudo, y no escribí ninguna. Qué observar: con modo 600, el segundo comando debe fallar con un mensaje Permission denied, porque labuser no es el propietario ni está en el grupo.

Después, libera el archivo para los demás:

chmod 644 notes.txt
sudo -u labuser cat ~/permlab/notes.txt

Qué observar: el contenido solo se imprime si labuser también puede entrar a tu carpeta personal y a ~/permlab. Muchas distribuciones crean las carpetas personales con 755, pero algunas usan 750. Si un directorio padre niega x a otros usuarios, la lectura falla aunque el archivo sea legible. Revisa con ls -ld ~ ~/permlab. En el Ubuntu 24.04 bajo WSL que usé, ls -ld ~ mostró drwxr-x---, es decir 750, así que un segundo usuario quedaría bloqueado ahí incluso después de chmod 644. Esta es la práctica del bit x de directorio que vimos antes.

#Buscar permisos riesgosos

Lista los archivos regulares escribibles por todos dentro de tu carpeta personal, sin cruzar a otros sistemas de archivos:

find ~ -xdev -type f -perm -o+w 2>/dev/null

En un laboratorio limpio, no imprime nada. Para ver la búsqueda funcionar, deja un archivo escribible a propósito:

chmod 666 ~/permlab/notes.txt
find ~ -xdev -type f -perm -o+w 2>/dev/null
chmod 644 ~/permlab/notes.txt

Observado: la primera búsqueda imprimió /home/usurio/permlab/notes.txt. Después de la corrección, la misma búsqueda no imprimió nada.

Lista los binarios setuid en un directorio del sistema:

find /usr/bin -perm -4000 -type f 2>/dev/null | sort

Observado en Ubuntu 24.04 bajo WSL, esto imprimió diez archivos, incluidos /usr/bin/passwd, /usr/bin/sudo, /usr/bin/su, /usr/bin/mount y /usr/bin/umount. Tu lista depende de la distribución y de los paquetes instalados. En una revisión, compara la lista con lo que el gestor de paquetes indica que debe ser setuid. Trata una entrada inesperada como una pregunta que hay que responder, no como prueba de un ataque.

Revisa el bit sticky en los directorios temporales:

stat -c '%a %A %n' /tmp /var/tmp

Observado: 1777 drwxrwxrwt en ambos. La t significa que los usuarios pueden crear archivos allí, pero no borrar archivos de otro usuario.

#Limpieza

rm -rf ~/permlab
sudo userdel -r labuser

userdel -r también borra la carpeta personal de la cuenta. Ejecútalo solo para la cuenta de laboratorio que creaste.

#Qué mostró la comprobación en Windows

Los mismos primeros pasos en Git Bash para Windows no se comportaron como en Linux. Después de chmod 600 notes.txt, stat siguió mostrando 644, y los chmod posteriores tampoco cambiaron la salida. Windows guarda el acceso en listas de control de acceso de NTFS, y Git Bash traduce solo algunos bits. Un laboratorio en Windows enseña los comandos, pero no puede demostrar qué hace un modo de Linux. Usa WSL con una distribución Linux, o una VM, para este artículo.

#Errores comunes

Usar 777 para arreglar un error de acceso denegado. Funciona, y además permite a todos escribir y ejecutar el archivo. Averigua qué clase está denegada y concede solo esa.

Olvidar el directorio. Un archivo legible puede seguir inaccesible si un directorio padre no da x al usuario. Revisa cada directorio de la ruta.

Usar chmod -R sobre un árbol completo. Los cambios recursivos suelen poner ejecución en archivos regulares o quitarla de los directorios. Usa find con -type f o -type d para apuntar a un solo tipo.

Confiar en el modo de un archivo copiado. cp, tar y las herramientas de archivado pueden conservar o reiniciar los modos según las opciones. Verifica el resultado con stat.

Leer la notación simbólica como absoluta. chmod g+w añade un bit. chmod g=w quita lectura y ejecución al grupo. La diferencia es fácil de pasar por alto.

Recurrir a root primero. Muchos problemas de lectura y escritura se resuelven con la pertenencia a un grupo o con el modo del directorio, no con un auxiliar setuid ni con un shell root.

#Por qué esto importa en las revisiones de seguridad

Una revisión de permisos empieza con una pregunta: ¿quién puede cambiar lo que un proceso privilegiado lee o ejecuta? Tres hallazgos aparecen una y otra vez:

1. Archivos escribibles en una ruta privilegiada. Una configuración o un script que lee un servicio root y que una cuenta normal puede escribir es una escalada esperando una edición.
2. Binarios setuid o setgid inesperados. Cada uno es código que corre con más derechos que quien lo invoca. Compara la lista con una línea base.
3. Directorios escribibles en una ruta de búsqueda o de servicio. Un usuario que puede crear o renombrar archivos allí puede reemplazar un archivo de confianza, aunque el archivo en sí esté bloqueado.

Al redactar un hallazgo, indica la ruta, el modo, el propietario, el grupo, el proceso que lo lee o ejecuta y el cambio que lo corrige. Prueba en tu laboratorio. No ejecutes estas búsquedas contra sistemas que no administras, y no uses sudo -u en la máquina de otra persona.

#Cómo seguir

Cuando los modos básicos estén claros, estudia las listas de control de acceso con getfacl y setfacl, que añaden entradas por usuario más allá de propietario, grupo y otros. Lee el manual de chattr sobre los atributos inmutable y de solo anexar. Usa namei -l /ruta/al/archivo para mostrar el modo de cada componente de una ruta. Es la forma más rápida de encontrar el directorio que bloquea un servicio.

Para los hábitos de shell detrás de estos comandos, empieza por el artículo anterior del Manual de Campo, fundamentos de Bash para estudiantes de seguridad. El próximo artículo, qué es SSH y cómo funcionan las claves SSH, trata sobre las claves SSH, que dependen de los mismos modos: el archivo de la clave privada debe ser legible solo por su propietario, y el cliente SSH se niega a usar una clave cuyo modo esté demasiado abierto.

El mínimo privilegio empieza en los modos de archivo. Un proceso que puede escribir menos hace menos daño cuando se equivoca, y un archivo que otros no pueden cambiar es una cosa menos que revisar.

#Fuentes

• Manual de GNU Coreutils, File permissions: https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html
• Página de manual de chmod(1), Linux man-pages: https://man7.org/linux/man-pages/man1/chmod.1.html
• Página de manual de umask(2), Linux man-pages: https://man7.org/linux/man-pages/man2/umask.2.html
• chmod, especificación de utilidades POSIX.1-2024, The Open Group: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/chmod.html