Mejores Prácticas para Asegurar Sistemas de Archivos Linux con Permisos Especiales
Domina la seguridad del sistema de archivos Linux aprovechando permisos especiales: SUID, SGID y el Sticky Bit. Esta guía explica cómo aplicar de forma segura estos modos usando notación octal para forzar el contexto de ejecución, asegurar la herencia de grupo en carpetas compartidas y prevenir la eliminación no autorizada de archivos en directorios como /tmp, proporcionando ejemplos prácticos para el endurecimiento del sistema.
Mejores Prácticas para Asegurar Sistemas de Archivos Linux con Permisos Especiales
Los permisos especiales son una de esas características de Linux que parecen pequeñas en ls -l y son muy importantes en producción. Una s adicional en un binario propiedad de root puede permitir a usuarios comunes realizar una tarea privilegiada limitada. Una t faltante en un directorio de carga compartido puede permitir a los usuarios eliminar archivos de otros. Un bit SGID en un directorio de proyecto puede ahorrarte un flujo constante de problemas de propiedad de grupo.
El objetivo no es esparcir bits especiales por todas partes. El objetivo es saber cuándo SUID, SGID y el sticky bit resuelven un problema de acceso real, y cuándo crean una ruta de privilegios que lamentarás después.
Comprendiendo los Permisos Estándar (Resumen)
Antes de explorar los permisos especiales, es esencial recordar la notación estándar de tripletes (rwx para propietario, grupo y otros). Estos permisos se representan numéricamente usando valores octales (por ejemplo, 755 o 644).
r(Lectura) = 4w(Escritura) = 2x(Ejecución) = 1
Los permisos especiales modifican este comportamiento base y se representan mediante un cuarto dígito octal inicial (4, 2 o 1).
Los Permisos Especiales: SUID, SGID y el Sticky Bit
Los permisos especiales añaden funcionalidad más allá del control de acceso estándar. Generalmente se denotan en la salida del listado largo (ls -l) mediante una s o t que reemplaza el indicador x estándar.
| Permiso | Valor Octal | Efecto |
|---|---|---|
| SUID (Set User ID) | 4 | El archivo se ejecuta con los permisos del propietario del archivo (no del usuario que lo ejecuta). |
| SGID (Set Group ID) | 2 | El archivo se ejecuta con los permisos del grupo del archivo, o los nuevos archivos heredan el ID de grupo del directorio padre. |
| Sticky Bit | 1 | Evita que los usuarios eliminen o renombren archivos propiedad de otros usuarios en un directorio compartido, incluso si tienen permiso de escritura en el directorio. |
1. Set User ID (SUID)
El bit SUID es potente y potencialmente peligroso si se usa incorrectamente. Cuando se establece en un archivo ejecutable, cualquier usuario que ejecute ese archivo ejecuta el proceso con los permisos del propietario.
Caso de Uso Práctico: Utilidades que requieren privilegios de root para realizar una tarea específica, pero que no deberían otorgar acceso general de root al usuario.
Ejemplo: SUID en /usr/bin/passwd
El comando /usr/bin/passwd típicamente requiere acceso de root para modificar el archivo seguro /etc/shadow. Tiene el bit SUID establecido, lo que permite a un usuario estándar obtener temporalmente los privilegios del propietario (root) solo durante la ejecución de passwd para cambiar su propia contraseña.
Visualizando SUID: Observa la s en la ranura de ejecución del propietario:
ls -l /usr/bin/passwd
# Ejemplo de salida: -rwsr-xr-x 1 root root ... /usr/bin/passwd
Estableciendo SUID: Usa el valor octal 4 combinado con permisos estándar (por ejemplo, 755 se convierte en 4755):
# Asumiendo que 'my_script' es propiedad de 'appuser'
chmod 4755 /path/to/my_script
Advertencia de Seguridad para SUID: Nunca establezcas el bit SUID en shells de propósito general (como
/bin/bash) o scripts de mantenimiento amplios que interpreten entrada externa. Si un script necesita privilegios, una reglasudoersestrecha, un pequeño helper revisado o una API de servicio suele ser más seguro.
Cuando auditas un host, los archivos SUID merecen atención porque son cruces de privilegios intencionales:
sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null
-xdev mantiene el escaneo en el sistema de archivos actual, lo cual es útil cuando /proc, copias de seguridad montadas o sistemas de archivos de red harían ruido en el resultado. En servidores con montajes separados, escanea cada sistema de archivos real intencionalmente.
2. Set Group ID (SGID)
El bit SGID tiene dos funciones principales dependiendo de si se aplica a un archivo o a un directorio.
A. SGID en Archivos Ejecutables
Cuando se establece en un archivo ejecutable, el proceso se ejecuta con los permisos asociados con la propiedad del grupo del archivo, no con el grupo principal del usuario.
B. SGID en Directorios (Crucial para Entornos Compartidos)
Cuando se establece en un directorio, cualquier nuevo archivo o subdirectorio creado dentro de él hereda automáticamente la propiedad del grupo del directorio padre, en lugar del grupo principal del usuario que creó el nuevo archivo.
Caso de Uso Práctico: Carpetas de proyectos compartidos donde todos los contribuyentes deben tener acceso de grupo unificado para la colaboración.
Estableciendo SGID en un Directorio: Usa el valor octal 2 combinado con permisos estándar (por ejemplo, 775 se convierte en 2775):
# Establecer la propiedad del grupo a 'developers' y habilitar SGID
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project
Eso maneja la herencia de grupo, pero no garantiza que cada nuevo archivo sea escribible por el grupo. El umask de un usuario todavía importa. Si los contribuyentes crean archivos con un umask restrictivo como 077, los archivos pueden heredar el grupo developers pero aún así ser ilegibles o no escribibles por el grupo. Para directorios compartidos, verifica el umask esperado, los ACL predeterminados o la configuración de creación de archivos a nivel de aplicación:
getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project
Los ACL predeterminados son a menudo la pieza faltante en directorios colaborativos porque aplican permisos a nuevos archivos y directorios creados debajo de la ruta.
3. El Sticky Bit
El Sticky Bit (o Atributo de Texto Guardado) se usa casi exclusivamente en directorios compartidos para controlar la eliminación de archivos.
Cuando el Sticky Bit está establecido en un directorio, solo el propietario de un archivo dentro de ese directorio, o el usuario root, pueden eliminar o renombrar ese archivo, incluso si el directorio mismo permite acceso de escritura para 'otros' (o+w).
Caso de Uso Práctico: Directorios compartidos públicos como /tmp o carpetas de carga departamentales donde los usuarios solo deberían poder gestionar los archivos que crearon.
Ejemplo: El Directorio /tmp
El directorio /tmp a menudo tiene permisos como 1777. El 1 indica que el Sticky Bit está activo.
ls -ld /tmp
# Ejemplo de salida: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp
La t al final confirma que el sticky bit está establecido. Sin él, cualquier usuario podría eliminar archivos creados por otros usuarios en /tmp.
Estableciendo el Sticky Bit: Usa el valor octal 1 combinado con permisos estándar (por ejemplo, 777 se convierte en 1777):
chmod 1777 /var/public_uploads
Gestión Integral: Combinando Permisos Especiales
Los permisos especiales a menudo se combinan. El cuarto dígito inicial es la suma de los bits especiales deseados (4+2+1 = 7).
| Permisos Deseados | Valor Octal |
|---|---|
Estándar rwxr-xr-x (755) |
755 |
SUID + rwxr-xr-x |
4755 |
SGID + rwxr-xr-x |
2755 |
Sticky Bit + rwxrwxrwx |
1777 |
SUID + SGID + Sticky Bit + rwx (Raramente necesario) |
7777 |
Ejemplo Combinando SGID y Sticky Bit para Carpetas Compartidas:
Para crear un directorio de colaboración compartido y seguro donde todos los usuarios sean parte del grupo 'team', los nuevos archivos hereden el grupo 'team' y los usuarios no puedan eliminar archivos de otros:
- Establecer la propiedad del grupo:
chgrp team /data/projectX - Aplicar SGID (2) + Estándar
rwx(7) + Sticky Bit (1) $\rightarrow 2+1 = 3$ para los bits especiales.- Usando la suma explícita: SGID (2) + Sticky Bit (1) = 3. Permisos estándar
775. - Comando total:
chmod 3775 /data/projectX
- Usando la suma explícita: SGID (2) + Sticky Bit (1) = 3. Permisos estándar
Al ver esto con ls -ld, deberías ver tanto s en la posición de ejecución del grupo como t en la posición de ejecución de otros:
drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX
Si falta el bit de ejecución, la visualización usa mayúsculas S o T. Eso suele ser una señal de advertencia en directorios, porque el permiso de ejecución controla si los usuarios pueden recorrer el directorio.
Errores Comunes que Causan Incidentes Reales
El error más peligroso es usar SUID para evitar diseñar una autorización adecuada. Si un script de mantenimiento necesita rotar un archivo propiedad de una aplicación, no hagas que todo el script sea efectivamente root para cada usuario. Dale a la aplicación un comando de servicio controlado, usa una regla sudoers estrecha o cambia la propiedad para que la cuenta de servicio pueda realizar la tarea sin root.
Otro error común es hacer que los directorios compartidos sean escribibles por el mundo sin el sticky bit:
chmod 777 /srv/uploads
Eso parece conveniente durante las pruebas. En producción, cualquier usuario local que pueda acceder al directorio podría renombrar o eliminar archivos de otro usuario. Si el directorio realmente debe ser escribible por muchos usuarios no relacionados, 1777 suele ser la línea base más segura:
chmod 1777 /srv/uploads
Para directorios propiedad del equipo, 2775 más un grupo real suele ser mejor que escritura mundial. Agrega el sticky bit solo si los miembros del equipo no deben eliminar archivos de otros. Algunos equipos quieren derechos de limpieza compartidos; otros no. El modelo de permisos debe coincidir con ese flujo de trabajo.
Las copias de seguridad y las implementaciones también pueden romper los permisos especiales. Algunas herramientas de archivo y copia preservan los modos por defecto; otras no a menos que pases las banderas correctas. Después de restaurar un sistema o implementar un paquete binario, verifica los bits especiales explícitamente:
stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project
Si /tmp vuelve como 0777 en lugar de 1777, eso no es una diferencia cosmética. Los usuarios pueden interferir con los archivos de otros. Si falta un bit SUID requerido en una utilidad del sistema, los usuarios comunes pueden perder repentinamente el comportamiento esperado. Si aparece un bit SUID inesperado en un archivo en /home, /tmp o una ruta de carga de aplicación, trátalo como sospechoso hasta que se demuestre lo contrario.
Auditoría sin Ahogarse en la Salida
Un escaneo completo del sistema de archivos puede ser ruidoso, especialmente en máquinas de compilación y estaciones de trabajo de desarrolladores. Comienza con las áreas que más importan:
sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
El primer comando revisa las ubicaciones normales de ejecutables. El segundo verifica áreas de scratch escribibles donde un ejecutable privilegiado sería mucho más preocupante. En un servidor limpio, los archivos SUID personalizados en rutas escribibles por el mundo deberían ser raros. Si encuentras uno, verifica la propiedad, la fuente del paquete, la hora de modificación y si aparece en tu gestión de configuración.
Para directorios, busca rutas escribibles por el mundo sin el sticky bit:
sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null
Esto no significa que cada resultado sea una brecha. Significa que cada resultado merece una razón. Algunos directorios de aplicaciones son intencionalmente escribibles por un grupo de servicio, pero los directorios públicos escribibles sin protección sticky son un error común.
Mejores Prácticas para la Seguridad de Permisos Especiales
Debido a los privilegios elevados que otorgan SUID y SGID, deben gestionarse con extrema precaución.
- Limitar el Alcance de SUID: Solo establece SUID en ejecutables binarios compilados que sean necesarios para operaciones estándar (como
passwd,ping). Nunca apliques SUID a scripts interpretados (Shell, Python, Perl) a menos que estén envueltos en un ejecutable contenedor seguro que valide la entrada. - Auditar Regularmente: Escanea periódicamente el sistema de archivos en busca de archivos SUID/SGID inusuales usando el comando
find:# Encontrar todos los archivos con SUID establecido find / -perm /4000 2>/dev/null # Encontrar todos los archivos con SGID establecido find / -perm /2000 2>/dev/null - Usar SGID para Consistencia de Grupo: Prefiere SGID sobre la gestión manual de la propiedad de grupo de archivos en estructuras de datos compartidas; automatiza la herencia de grupo.
- Sticky Bit para Áreas Escribibles Públicas: El Sticky Bit es esencial para cualquier directorio destinado al uso general de usuarios donde la eliminación por no propietarios debe estar restringida (por ejemplo,
/tmp,/var/tmp). - Combinar SGID con ACLs cuando la colaboración importa: SGID maneja la propiedad del grupo; los ACL predeterminados manejan los permisos que reciben los nuevos archivos.
- Rastrear Excepciones Personalizadas: Si tu organización aprueba un binario SUID o SGID personalizado, registra el propósito, propietario, ruta esperada y fuente de implementación. El privilegio misterioso es la parte que duele después.
Los permisos especiales son útiles porque son precisos. Mantenlos así. Usa SUID para transiciones de privilegios estrechas, SGID para propiedad compartida y el sticky bit para directorios compartidos donde los derechos de eliminación necesitan protecciones.