8 permisos de Linux que pueden convertirse en un riesgo de seguridad

Un servidor Linux puede estar actualizado, protegido por firewall y configurado con políticas estrictas de SSH y, aun así, mantener una vía de entrada mucho más sencilla: permisos mal asignados. Un script modificable por cualquier usuario, una clave privada demasiado accesible o un servicio de systemd que ejecuta un archivo escribible por una cuenta sin privilegios pueden convertir un pequeño descuido administrativo en acceso a información sensible o escalada de privilegios.

Las claves de los permisos peligrosos en Linux en 30 segundos

• Los binarios SUID/SGID y las capabilities pueden proporcionar privilegios inesperados a procesos aparentemente normales.
• Archivos y directorios escribibles por cualquier usuario deben revisarse, especialmente cuando intervienen procesos privilegiados.
• /etc/shadow, las claves SSH y authorized_keys necesitan propietarios y permisos adecuados.
• Cron y systemd pueden convertirse en vías de escalada si ejecutan archivos modificables por usuarios sin privilegios.
• Pertenecer al grupo docker o acceder a /var/run/docker.sock puede equivaler en muchos escenarios a disponer de privilegios de root.

Los permisos no suelen recibir la misma atención que una vulnerabilidad crítica o un ataque contra SSH. Sin embargo, forman parte de la primera línea de seguridad del sistema operativo: determinan quién puede leer, escribir y ejecutar cada recurso.

El objetivo tampoco consiste en eliminar permisos de forma indiscriminada. Linux necesita directorios compartidos, ejecutables privilegiados y servicios con diferentes niveles de acceso. La administración segura pasa por detectar aquello que no debería estar expuesto y aplicar el principio de mínimo privilegio.

1. Binarios SUID y SGID que nadie recuerda haber instalado

Los bits SUID (Set User ID) y SGID (Set Group ID) permiten que un programa se ejecute con determinados permisos de su propietario o grupo en lugar de limitarse a los del usuario que lo inicia.

Son mecanismos legítimos, pero un ejecutable desconocido con SUID puede convertirse en una vía de escalada si contiene una vulnerabilidad o ha sido instalado maliciosamente.

Una primera auditoría puede realizarse con:

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f \
  -exec ls -la {} \; 2>/dev/null

Además de revisar la lista, resulta útil mantener una referencia del estado esperado:

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f \
  2>/dev/null | sort > suid-baseline.txt

Posteriormente puede compararse con el estado actual. Cualquier ejecutable nuevo merece una explicación: qué paquete lo instaló, cuándo apareció y por qué necesita esos privilegios.

2. Archivos y directorios modificables por cualquier usuario

Un archivo world-writable permite escribir en él a cualquier usuario del sistema. El riesgo aumenta considerablemente cuando ese archivo termina siendo ejecutado por root o por otro proceso privilegiado.

Por ejemplo:

-rwxrwxrwx 1 root root 1842 Aug 18 09:20 backup.sh

Si backup.sh se ejecuta posteriormente como root, un usuario con pocos privilegios podría modificar su contenido para introducir otros comandos.

Los archivos afectados pueden localizarse mediante:

find / -xdev -type f -perm -002 2>/dev/null

Para buscar directorios escribibles por todos que además carecen del sticky bit:

find / -xdev -type d -perm -002 ! -perm -1000 2>/dev/null

No todos los resultados son errores. /tmp y /var/tmp, por ejemplo, están diseñados para ser compartidos. En estos casos debe comprobarse el sticky bit:

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

Eliminar permisos automáticamente de todos los resultados puede romper aplicaciones. Cada caso debe revisarse antes de utilizar chmod o-w.

3. /etc/shadow y otros archivos sensibles con permisos incorrectos

No todos los archivos de /etc tienen que permanecer ocultos. /etc/passwd y /etc/group, por ejemplo, normalmente son legibles por todos los usuarios.

La situación es diferente con /etc/shadow y /etc/gshadow, que almacenan información protegida relacionada con autenticación.

Su estado puede comprobarse con:

stat -c '%A %a %U:%G %n' \
  /etc/passwd /etc/shadow /etc/group /etc/gshadow

Dependiendo de la distribución, /etc/shadow suele utilizar permisos 640 o 600 y propietarios como root:shadow o root:root.

Antes de modificarlo conviene consultar la configuración esperada por la distribución. Aplicar ciegamente una receta genérica puede ser tan problemático como mantener unos permisos incorrectos.

El mismo criterio debe extenderse a archivos de configuración que contengan contraseñas, tokens, claves API o credenciales de aplicaciones.

4. Claves SSH y directorios .ssh demasiado abiertos

La autenticación mediante claves SSH depende también de los permisos del sistema de archivos.

Una clave privada accesible por otro usuario puede copiarse. Un authorized_keys modificable por una cuenta no autorizada plantea otro problema: esa cuenta podría añadir una nueva clave pública y obtener posteriormente acceso SSH.

Una configuración habitual utiliza:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

También debe comprobarse el propietario.

Pero los permisos correctos no solucionan otro problema frecuente: claves antiguas que nadie ha retirado. Revisar periódicamente authorized_keys permite eliminar accesos de empleados, proveedores, automatizaciones o equipos que ya no los necesitan.

5. Reglas de sudo más amplias de lo necesario

sudo permite delegar operaciones administrativas concretas sin proporcionar directamente una sesión completa como root. Una configuración demasiado permisiva puede anular esa ventaja.

Una regla como:

user ALL=(ALL) NOPASSWD: ALL

concede un nivel de acceso extraordinariamente amplio sin solicitar contraseña.

También deben revisarse los comodines y programas capaces de ejecutar comandos adicionales. Editores, intérpretes, shells y algunas utilidades aparentemente inocentes pueden permitir escapar del comando autorizado y obtener una shell privilegiada.

La sintaxis puede comprobarse con:

sudo visudo -c

Y las reglas potencialmente amplias pueden localizarse inicialmente mediante:

grep -rP '(NOPASSWD|ALL)' /etc/sudoers /etc/sudoers.d/ 2>/dev/null

El resultado necesita revisión manual. Encontrar ALL no implica automáticamente una vulnerabilidad.

6. Cron y systemd ejecutando archivos modificables por usuarios

Una tarea programada que se ejecuta como root merece tanta atención como cualquier binario privilegiado.

El problema aparece cuando el proceso ejecuta un script que puede modificar un usuario sin privilegios. El atacante no necesita controlar cron: le basta con cambiar aquello que root ejecutará posteriormente.

Las tareas pueden empezar a revisarse mediante:

crontab -l -u root
cat /etc/crontab /etc/cron.d/* 2>/dev/null

En systemd resulta útil comprobar los temporizadores:

systemctl list-timers --all

También pueden buscarse unidades con permisos de escritura excesivos:

find /etc/systemd/system /usr/lib/systemd/system \
  -type f -name '*.service' -perm -022 2>/dev/null

La auditoría debe llegar hasta ExecStart y los archivos realmente ejecutados. Una unidad correctamente protegida sigue siendo problemática si llama a un script modificable por cualquier usuario.

7. Linux capabilities: privilegios elevados sin SUID

Auditar únicamente SUID y SGID ya no resulta suficiente.

Las Linux capabilities permiten conceder privilegios concretos a un ejecutable sin entregarle todos los permisos de root. Es un mecanismo más preciso, pero una capability innecesaria continúa siendo peligrosa.

El inventario puede obtenerse con:

getcap -r / 2>/dev/null

Entre las que requieren especial atención aparecen cap_setuid, que permite modificar el identificador de usuario de un proceso, y la muy amplia cap_sys_admin.

Cuando una capability no resulta necesaria puede retirarse, tras verificar previamente las consecuencias:

sudo setcap -r /path/to/binary

Aquí también resulta útil conservar un baseline y comprobar qué cambia después de actualizaciones o instalaciones de software.

8. El socket de Docker y el acceso que prácticamente equivale a root

El último permiso suele pasar desapercibido porque no parece un permiso tradicional de Linux.

El daemon de Docker expone normalmente:

/var/run/docker.sock

Los usuarios con acceso a este socket pueden enviar instrucciones al daemon. En una configuración convencional, pertenecer al grupo docker debe considerarse un privilegio muy elevado, ya que puede permitir crear contenedores con acceso al host y terminar obteniendo control equivalente al de root.

El primer paso es comprobar el socket:

ls -l /var/run/docker.sock

Y revisar los miembros del grupo:

getent group docker

También hay que vigilar los contenedores que reciben directamente el socket mediante montajes como:

-v /var/run/docker.sock:/var/run/docker.sock

Entregar ese recurso a una aplicación comprometida o a un contenedor no confiable amplía considerablemente las consecuencias de una intrusión.

Auditar permisos antes de buscar problemas más sofisticados

Ninguna de estas revisiones sustituye al parcheado, firewall, endurecimiento de SSH, SELinux o AppArmor, monitorización y demás controles de seguridad. Los permisos forman otra capa y, precisamente por su sencillez, pueden quedar olvidados durante años.

Una estrategia práctica consiste en inventariar, crear referencias conocidas y revisar los cambios después de instalar software o modificar servicios. SUID, SGID y capabilities son buenos candidatos para este modelo.

Los administradores también deben prestar especial atención a cualquier cadena en la que un usuario con pocos privilegios pueda modificar algo que posteriormente ejecutará un proceso privilegiado.

Ese patrón aparece repetidamente en cron, systemd, scripts de backup, herramientas internas y automatizaciones.

Antes de buscar una vulnerabilidad sofisticada, una auditoría puede empezar con cuatro preguntas mucho más sencillas: quién puede leer, quién puede escribir, quién puede ejecutar y bajo qué usuario terminará ejecutándose ese archivo.

Preguntas frecuentes

¿Cómo buscar archivos con SUID o SGID en Linux?

Puede utilizarse find con los permisos -4000 y -2000. Conviene guardar además un inventario de referencia para detectar ejecutables privilegiados que aparezcan posteriormente.

¿Es peligroso pertenecer al grupo docker?

Debe considerarse un acceso altamente privilegiado en una instalación Docker convencional. Un usuario capaz de controlar el daemon puede crear contenedores con acceso a recursos sensibles del host y, en muchos escenarios, obtener privilegios equivalentes a root.

¿Qué permisos debe tener una clave privada SSH?

Habitualmente las claves privadas utilizan 600, mientras que el directorio .ssh utiliza 700. También deben pertenecer al usuario correspondiente y nunca quedar accesibles para cuentas que no las necesiten.

¿Todos los directorios world-writable son inseguros?

No. Directorios compartidos como /tmp necesitan ser escribibles por múltiples usuarios. Lo importante es que tengan las protecciones apropiadas, como el sticky bit, y revisar cualquier ubicación escribible por todos que sea utilizada por procesos privilegiados.