Permisos, procesos y logs en Linux

Debajo de cada contenedor, cada función y cada base de datos gestionada hay, casi siempre, un kernel Linux. Es el sistema operativo donde corren tus cargas y, lo que más nos importa aquí, de donde salen las señales cuando algo va mal: quién ejecutó qué, con qué identidad y qué tocó. Entender permisos, procesos y logs es la base para aplicar mínimo privilegio en el host, detectar un abuso e investigarlo después. Lo veremos sobre una EC2 que forma parte de la app de referencia, Citas.

El modelo de permisos#

En Linux casi todo es un fichero, y cada fichero tiene un dueño, un grupo y un conjunto de permisos para tres clases de usuario: el dueño (user), el grupo (group) y el resto (others). Para cada clase hay tres bits: lectura (r), escritura (w) y ejecución (x). En un directorio cambian de sentido: r lista su contenido, w permite crear o borrar entradas y x permite atravesarlo.

$ ls -l /opt/citas
-rwxr-x--- 1 root  citas  8421 oct  9 10:12 citas-maint
-rw-r----- 1 citas citas  1920 oct  9 10:12 config.yaml

Se lee así: citas-maint es de root, grupo citas; el dueño tiene rwx, el grupo r-x y los demás nada. Esos nueve bits se expresan también en octal, sumando por clase 4 (r) + 2 (w) + 1 (x):

rwx = 7, r-x = 5, r-- = 4, --- = 0 → citas-maint es 750.
config.yaml es rw-r----- = 640.

Los cambias con chmod (permisos) y chown (dueño y grupo):

# Solo el dueño lee y escribe; el grupo solo lee; nadie más accede
$ chmod 640 config.yaml
# El servicio corre como citas:citas, no como root
$ chown citas:citas config.yaml

Permisos y escalada por setuid

Linux · Permisos

Paso 1 de 5Dueño · grupo · otros

Cada fichero tiene permisos rwx para tres clases: su dueño, su grupo y el resto. El script de mantenimiento de la EC2 es de root, grupo citas, con modo 750.

Los bits especiales: setuid, setgid y sticky#

Sobre esos nueve bits hay tres bits especiales que cambian el comportamiento, y dos de ellos son una fuente clásica de escalada de privilegios.

setuid (chmod u+s, aparece como s en la x del dueño): el proceso que ejecuta el binario adopta el UID del dueño, no el de quien lo lanza. passwd es el ejemplo legítimo: necesita escribir en /etc/shadow, que es de root, así que es setuid-root.
setgid (g+s): lo análogo con el grupo. En un directorio hace además que los ficheros nuevos hereden el grupo del directorio.
sticky bit (+t, la t en la x de otros): en un directorio compartido como /tmp, solo el dueño de cada fichero puede borrarlo, aunque todos puedan escribir en el directorio.

El riesgo del setuid es directo: un binario setuid-root con un fallo, o colocado por un atacante, concede root a cualquiera que lo ejecute. Es exactamente lo que anima el explainer de arriba. Por eso un host endurecido audita y minimiza estos binarios.

# Inventaría todos los binarios setuid-root del host
$ find / -xdev -perm -4000 -type f -exec ls -l {} \; 2>/dev/null
-rwsr-xr-x 1 root root 68208 /usr/bin/passwd
-rwsr-xr-x 1 root root 55528 /usr/bin/sudo

Usuarios, sudo y root#

root (UID 0) salta todas las comprobaciones de permisos. El principio operativo es no iniciar sesión como root ni dejar que los servicios corran como root: cada servicio con su propio usuario de sistema sin shell (citas, nginx…), y las tareas administrativas puntuales vía sudo, que ejecuta un comando como otro usuario dejando registro de quién lo pidió.

# El operador solo puede reiniciar el servicio, nada más. Queda en el log.
operador  ALL=(root) NOPASSWD: /usr/bin/systemctl restart citas

Una regla sudo tan estrecha es mucho mejor que un binario setuid-root: el permiso es explícito, auditable y limitado a una acción.

Procesos, UID efectivo y señales#

Un proceso es un programa en ejecución, con un PID, un padre (forma el árbol de procesos) y una identidad. Esa identidad tiene matiz: el UID real es quién lo lanzó y el UID efectivo es con qué permisos actúa ahora mismo. El setuid es justo lo que hace que diverjan.

# Árbol de procesos: quién es hijo de quién (clave para ver un proceso anómalo)
$ ps -ef --forest
# Identidad real y efectiva de un proceso
$ ps -o pid,ruser,euser,comm -p 3120
  PID RUSER   EUSER   COMMAND
 3120 citas   citas   node

Que un node del servicio tenga EUSER root, o que una shell cuelgue de un proceso web, son señales de alarma. A los procesos se les envían señales: SIGTERM (15) pide terminar de forma ordenada, SIGKILL (9) lo mata sin opción a limpiar y SIGHUP (1) suele usarse para recargar configuración. kill -9 es el último recurso, no el primero.

Logs: de dónde salen las señales#

Aquí está el valor defensivo. Si no registras lo que pasa en el host, un compromiso es invisible y la investigación posterior, imposible. En Linux moderno conviven dos piezas:

systemd-journald recoge en un formato binario estructurado los logs del kernel y de los servicios; se consultan con journalctl. Muchas distribuciones lo reenvían además a syslog (rsyslog), que escribe en texto bajo /var/log y puede reenviar a un colector central por red.

# Todo lo del servicio citas desde el último arranque
$ journalctl -u citas -b --no-pager
# Autenticaciones (SSH, sudo): intentos fallidos incluidos
$ journalctl _COMM=sshd | grep -i "failed\|accepted"

Los ficheros clásicos siguen ahí y conviene saber cuál mira cada cosa:

/var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/Amazon Linux): logins, sudo, SSH.
/var/log/syslog o /var/log/messages: mensajes generales del sistema.
/var/log/audit/audit.log: la salida de auditd (ver pestaña).

auditd es el subsistema de auditoría del kernel. Va más allá de los logs de aplicación: registra llamadas al sistema y accesos a ficheros según reglas que tú defines. Es la base de la detección en el host.

# Alerta si alguien toca el fichero de contraseñas
-w /etc/shadow -p wa -k ident-cambios
# Registra cada ejecución de un binario con setuid (posible escalada)
-a always,exit -F arch=b64 -C euid!=uid -F euid=0 -S execve -k escalada

Por qué importan para detección e investigación: cuando GuardDuty o un analista marcan una EC2 como sospechosa, estas son las fuentes que reconstruyen la historia —qué usuario entró, qué sudo se ejecutó, qué binario setuid corrió, qué fichero sensible se tocó—. En AWS, el CloudWatch agent envía /var/log/secure y audit.log a CloudWatch Logs, fuera del host.

Errores habituales#

chmod 777 para “que funcione”. Da escritura y ejecución a cualquiera; es la puerta a que un proceso web escriba un binario y lo ejecute. Casi nunca es la solución correcta.
Servicios corriendo como root “porque es más fácil”. Multiplica el radio de impacto de cualquier fallo de ese servicio.
No mirar los logs hasta que hay un incidente. Sin un baseline de lo normal, no distingues una escalada del ruido del día a día.

Tu turno

Audita permisos, setuid y logs en tu propio host

Sobre una máquina Linux tuya (un servidor de laboratorio, una VM, tu WSL), no de producción ajena:

Lista los binarios setuid-root: find / -xdev -perm -4000 -type f 2>/dev/null. ¿Reconoces todos? Busca qué hace cada uno que te suene raro.
Mira quién puede hacer sudo y con qué alcance (sudo -l). ¿Hay alguna regla más amplia de lo necesario?
Revisa los logins recientes con journalctl _COMM=sshd o last. ¿Ves intentos fallidos? ¿Desde dónde?
Escribe una regla de auditd que vigile un fichero que te importe y comprueba que audit.log registra el acceso.

Apunta qué te sorprendió: casi siempre aparece algún permiso o acceso que no esperabas.

Reto

Un binario es -rwsr-xr-x y de root. Un usuario sin privilegios lo ejecuta. ¿Con qué UID efectivo corre el proceso y por qué es un riesgo?

▸Mostrar solución

Con UID efectivo 0 (root): la s en la posición de ejecución del dueño es el bit setuid, que hace que el proceso adopte la identidad del dueño del fichero, no la de quien lo lanza. Es un riesgo porque, si ese binario tiene un fallo o permite ejecutar comandos, cualquier usuario obtiene privilegios de root. El mínimo privilegio prefiere una capability concreta o una regla sudo acotada.