Esecuzione con privilegi minimi e disciplina nell'uso di sudo

La maggior parte delle violazioni della sicurezza nell'automazione non avviene a causa di exploit sofisticati, ma perché gli script vengono eseguiti con più privilegi del necessario. Un cron job eseguito come root che deve solo ruotare un file di log è un incidente in attesa di verificarsi.

Il principio del privilegio minimo stabilisce che ogni processo debba operare usando solo i permessi necessari per svolgere il proprio compito, e nessun altro. Negli script Bash questo significa:

• eseguire il processo come utente non privilegiato ogni volta che è possibile
• acquisire i privilegi di root solo per i comandi specifici che li richiedono
• abbandonare i privilegi non appena il lavoro con privilegi elevati è terminato
• non memorizzare né ereditare mai le credenziali oltre il loro ambito

Questa lezione illustra tecniche concrete: definizione dell'ambito di sudo, abbandono dei privilegi con su, controlli di convalida dell'UID e rafforzamento di sudoers, per costruire un modello disciplinato dei privilegi negli script di produzione.

Prima di qualsiasi blocco di codice che richieda realmente root, lo script dovrebbe verificare di essere eseguito con l'UID effettivo previsto. Non date nulla per scontato: verificate sempre.

$EUID è una variabile speciale di Bash che contiene l'ID utente effettivo del processo corrente. Root ha sempre EUID 0. Controllarlo all'inizio dello script, o intorno a un blocco privilegiato, impedisce l'esecuzione accidentale con l'identità sbagliata.

Usate questo pattern di controllo:

Alcuni script hanno legittimamente bisogno di root. In tal caso, il controllo funziona al contrario: terminare subito se root non è disponibile, invece di lasciare che lo script raggiunga una syscall privilegiata e produca un errore di permessi poco chiaro durante l'esecuzione.

Combinare l'uscita anticipata con un messaggio d'uso utile rende gli script autoesplicativi:

L'errore più comune consiste nel mettere sudo all'inizio di uno script e poi eseguire tutto come root. Applicate invece sudo solo al comando esatto che ne ha bisogno: tutto il resto viene eseguito come utente normale.

In questo modo si limita il raggio d'azione: se un attaccante inserisce codice nello script, può eseguire con permessi di root solo le parti precedute da sudo.

Confrontate i due pattern seguenti. Il secondo è nettamente più sicuro:

Richiamare sudo somecommand in uno script è sicuro solo se il file sudoers è configurato per consentire esattamente quel comando, e nient'altro. Evitate regole come ALL=(ALL) NOPASSWD: ALL per gli account di servizio.

Limitate invece le regole a comandi specifici con argomenti specifici, usando la sintassi sicura per visudo. Campi principali di una regola sudoers:

• User — chi può invocare sudo
• Host — su quale macchina (usate ALL per la portabilità)
• RunAs — quale identità assumere (quasi sempre root)
• Command — percorso assoluto completo, facoltativamente con argomenti letterali

Esempi di regole restrittive per un account di servizio di deployment (deployer):

Quando uno script viene avviato come root (ad esempio da un sistema init o da cron in esecuzione come root), ma la maggior parte del lavoro dovrebbe essere svolta da un utente non privilegiato, abbandonate esplicitamente i privilegi invece di eseguire l'intero script come root.

Due strumenti per farlo:

• su -s /bin/bash -c 'command' username — avvia una shell come username ed esegue il comando
• runuser -u username -- command args — preferibile su Linux per il cambio di utente all'interno di script di proprietà di root; è più pulito di su

Il pattern seguente mostra un wrapper di deployment di proprietà di root che passa all'utente app per la logica effettiva dell'applicazione:

Non è sempre necessario avviare una sessione shell completa. sudo -u username command esegue un singolo comando come l'utente specificato, quindi torna all'identità chiamante. È utile per modificare file di proprietà di un account di servizio senza concedere a quell'account alcun accesso interattivo.

Abbinate questa tecnica a una regola sudoers che consenta esattamente quella combinazione di utente e comando:

Una superficie d'attacco sottile è rappresentata dalle variabili d'ambiente ereditate da una sessione sudo. Per impostazione predefinita, sudo reimposta l'ambiente, ma configurazioni errate di env_keep o override di env_reset possono passare variabili controllate dall'attaccante, come LD_PRELOAD, PATH o PYTHONPATH, ai comandi privilegiati.

Buone pratiche:

• Usate sempre percorsi assoluti negli script eseguiti tramite sudo: non fate mai affidamento su $PATH
• Passate solo le variabili esplicitamente necessarie: sudo env VAR=value /path/to/cmd
• In sudoers, evitate env_keep += PATH o env_keep += LD_*
• Usate sudo -E solo quando controllate completamente e considerate attendibile l'ambiente chiamante

Anche quando una regola sudoers consente uno script specifico, a tale script possono essere passati argomenti arbitrari, a meno che anche questi non siano limitati dalla regola. Un errore comune è il seguente:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Questo consente sudo /opt/scripts/manage.sh restart, ma anche sudo /opt/scripts/manage.sh --arbitrary-flag. Se manage.sh passa gli argomenti senza controlli ai sottocomandi privilegiati, avete un problema.

Applicate la difesa in profondità: convalidate gli argomenti all'interno dello script privilegiato e anche in sudoers:

Quando uno script deve disporre brevemente di un file, una credenziale o una risorsa con privilegi elevati, utilizzi trap di Bash per garantire che la pulizia venga eseguita anche in caso di errore o di segnale. In questo modo si evitano fughe di privilegi, ad esempio un binario setuid temporaneo o un socket di proprietà di root lasciato sul sistema se lo script va in crash.

Il modello seguente crea un file temporaneo come root, lo utilizza e poi lo rimuove: l'operazione è garantita da una trap su EXIT:

Il principio del privilegio minimo è più facile da applicare quando ogni evento di elevazione viene registrato con il relativo contesto: chi ha eseguito l'operazione, che cosa, quando e perché. Combini due livelli:

1. sudo stesso — /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL) registra automaticamente ogni invocazione di sudo
2. Registro di audit a livello di script — scriva una voce strutturata all'inizio di ogni funzione con privilegi, in modo che l'intento venga registrato insieme al log di sistema

L'utilizzo di una semplice funzione per i log strutturati mantiene coerenti e facili da cercare con grep le tracce di audit:

Verifichi la propria comprensione dell'esecuzione con privilegi minimi negli script Bash.

In questa lezione ha acquisito le tecniche per eseguire gli script Bash con il livello minimo di privilegi necessario in ogni passaggio. Ecco un riepilogo conciso dei principi fondamentali:

• Verifichi con $EUID — interrompa subito l'esecuzione se lo script viene eseguito con l'identità sbagliata, sia che ciò significhi rifiutare root, sia che ne richieda l'uso
• Limiti sudo ai singoli comandi — non elevi mai i privilegi di un intero script; applichi sudo solo alle righe che ne hanno realmente bisogno
• Scriva regole sudoers restrittive — specifichi i percorsi assoluti completi e gli argomenti letterali; eviti i caratteri jolly e ALL
• Rinunci ai privilegi con runuser o sudo -u — quando uno script avviato da root deve passare il controllo a un utente senza privilegi, utilizzi lo strumento appropriato invece di eseguire tutto come root
• Utilizzi percorsi assoluti — non faccia mai affidamento su $PATH all'interno del codice con privilegi; codifichi direttamente i percorsi dei binari per impedire il loro dirottamento
• Convalidi gli argomenti all'interno degli script con privilegi — le regole sudoers sono la prima linea di difesa, non l'unica; utilizzi delle allowlist
• Imposti una trap e pulisca le risorse — utilizzi trap cleanup EXIT per garantire che le risorse temporanee con privilegi vengano distrutte anche in caso di errore
• Registri ogni elevazione — le voci di audit strutturate, unite al syslog integrato di sudo, garantiscono la tracciabilità di ogni azione con privilegi

Applicate con coerenza, queste pratiche riducono la superficie di attacco della Sua automazione da root sempre a root solo dove è dimostrabilmente necessario: il segno distintivo di Bash consolidato e adatto alla produzione.