Come Leggere i Log di Linux Senza Root (Guida alle Autorizzazioni)

Nella maggior parte delle distribuzioni, due appartenenze a gruppi coprono quasi tutto ciò di cui un analista ha bisogno: adm per i log di testo in /var/log su Debian e Ubuntu, e systemd-journal per l’intero journal di sistema. Aggiungi l’account con sudo usermod -aG adm,systemd-journal <user> e avvia una nuova sessione di login. Alcuni log restano riservati solo al root per scelta, in particolare /var/log/secure e /var/log/messages sui sistemi della famiglia Red Hat e tutto sotto /var/log/audit. Per questi, utilizza sudo con ambito limitato, non una shell root.

Dare a qualcuno l’accesso root solo per poter leggere i log è il tipo di scorciatoia che emerge nel prossimo audit o incidente. Questa guida copre il modo del minimo privilegio, oltre alle trappole che rendono “aggiungerli semplicemente a un gruppo” meno semplice di quanto sembri.

Inizia gratis

Chi può leggere cosa

La proprietà esatta varia con la distribuzione e la versione, quindi verifica direttamente sulla macchina:

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

Opzione 1: Appartenenza al gruppo

sudo usermod -aG adm,systemd-journal analyst

Due dettagli sono importanti. L’opzione -a non è opzionale: senza di essa, usermod -G sostituisce i gruppi dell’utente invece di aggiungerli. E i cambiamenti nei gruppi si applicano solo alle nuove sessioni. Effettua il logout e il login di nuovo, o avvia una nuova shell di login, prima di testare. “Ho aggiunto il gruppo e continua a dire permesso negato” è quasi sempre dovuto a una sessione vecchia.

Su sistemi della famiglia Red Hat, adm non sblocca /var/log/secure o /var/log/messages. Questi file sono riservati solo al root lì. Usa l’opzione 2 o 3.

Opzione 2: Sudo limitato per i log solo root

Concedi comandi specifici, non una 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 è un piccolo script di proprietà del root (modalità 0755, di proprietà del root) che fa esattamente una cosa:

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

Perché un wrapper invece di cat /var/log/secure* in sudoers? Perché un * in un argomento sudoers corrisponde a qualsiasi cosa, spazi inclusi. cat /var/log/secure /etc/shadow corrisponde a cat /var/log/secure*. Un wrapper senza argomenti non ha un tale buco.

Non concedere journalctl tramite sudo. Apre un pager (less), e !sh all’interno di less ti dà una shell root. Per l’accesso al journal, usa il gruppo systemd-journal.

Opzione 3: Proprietà di gruppo che sopravvive alla rotazione

Impostare direttamente un ACL funziona fino alla prossima rotazione: sudo setfacl -m g:logreaders:r /var/log/secure. Poi il file viene ricreato e l’ACL scompare. Per rendere l’accesso permanente, fai in modo che i nuovi file vengano creati con il giusto gruppo in primo luogo, in entrambi i posti che li creano:

• logrotate, nello stanzino del file: create 0640 root logreaders
• rsyslog, sull’azione che lo scrive: action(type=”omfile” file=”/var/log/secure” fileGroup=”logreaders” fileCreateMode=”0640″)

Testalo con logrotate -f su una macchina non di produzione prima di distribuirlo.

Container

Non aggiungere gli analisti al gruppo docker solo per leggere i log dei container. L’appartenenza a docker è praticamente equivalente a root su quell’host. Ottieni i log dei container dal tuo raccoglitore di log o SIEM, oppure chiedi al team della piattaforma accesso in sola lettura lì.

Quando qualcosa va male