Cómo Leer Registros de Linux Sin Root (Guía de Permisos)

En la mayoría de las distribuciones, dos membresías de grupo cubren casi todo lo que un analista necesita: adm para los registros de texto en /var/log en Debian y Ubuntu, y systemd-journal para el registro completo del sistema. Añade la cuenta con sudo usermod -aG adm,systemd-journal <user> y comienza una nueva sesión de inicio. Algunos registros permanecen solo accesibles por root por diseño, notablemente /var/log/secure y /var/log/messages en sistemas de la familia Red Hat y todo bajo /var/log/audit. Para estos, usa sudo con alcance reducido, no un shell root.

Dar permiso de root solo para que alguien pueda leer registros es el tipo de atajo que aparece en la próxima auditoría o en el próximo incidente. Esta guía cubre la manera de menor privilegio, además de las trampas que hacen que “solo agréguelos a un grupo” sea menos simple de lo que parece.

Comienza gratis

Quién puede leer qué

La propiedad exacta varía con la distribución y versión, así que comprueba en la propia caja:

id
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
getfacl /var/log/journal 2>/dev/null

Opción 1: Membresía de grupo

sudo usermod -aG adm,systemd-journal analista

Dos detalles son importantes. El -a no es opcional: sin él, usermod -G reemplaza los grupos del usuario en lugar de añadir a ellos. Y los cambios de grupo solo se aplican a nuevas sesiones. Cierra sesión y vuelve a iniciarla o comienza un nuevo shell de inicio antes de probar. “He añadido el grupo y todavía dice permiso denegado” es casi siempre una sesión antigua.

En sistemas de la familia Red Hat, adm no desbloquea /var/log/secure o /var/log/messages. Esos archivos son solo accesibles por root allí. Usa la Opción 2 o 3.

Opción 2: Sudo reducido para registros solo de root

Concede comandos específicos, no un shell. Crea /etc/sudoers.d/log-readers con visudo -f:

%logreaders ALL=(root) NOPASSWD: /usr/sbin/ausearch, /usr/local/bin/read-secure-log

read-secure-log es un pequeño script propiedad de root (modo 0755, propiedad de root) que hace exactamente una cosa:

#!/bin/sh
exec /usr/bin/zcat -f /var/log/secure /var/log/secure-*

¿Por qué un envoltorio en lugar de cat /var/log/secure* en sudoers? Porque un * en un argumento de sudoers coincide con cualquier cosa, incluidos espacios. cat /var/log/secure /etc/shadow coincide con cat /var/log/secure*. Un envoltorio sin argumentos no tiene tal agujero.

No concedas journalctl a través de sudo. Abre un paginador (less), y !sh dentro de less te da un shell root. Para el acceso al registro, usa el grupo systemd-journal en su lugar.

Opción 3: Propiedad de grupo que sobrevive a la rotación

Configurar un ACL directamente funciona hasta la próxima rotación: sudo setfacl -m g:logreaders:r /var/log/secure. Luego, el archivo se recrea y el ACL desaparece. Para que el acceso se mantenga, haz que los nuevos archivos se creen con el grupo correcto desde el principio, en ambos lugares que los crean:

• logrotate, en el estrofa del archivo: create 0640 root logreaders
• rsyslog, en la acción que lo escribe: action(type=»omfile» file=»/var/log/secure» fileGroup=»logreaders» fileCreateMode=»0640″)

Prúebalo con logrotate -f en una caja no producción antes de implementarlo.

Contenedores

No añadas analistas al grupo docker solo para leer registros de contenedores. La membresía en docker es efectivamente root en ese host. Obtén los registros del contenedor de tu colector de registros o SIEM en su lugar, o pide al equipo de la plataforma acceso de solo lectura allí.

Cuando algo sale mal