5 nuove funzionalità sudo che gli amministratori di sistema devono conoscere nel 2022

Le recenti versioni di sudo hanno aggiunto nuove funzionalità che ti consentono di osservare e controllare aree problematiche precedentemente nascoste.

Quando vuoi concedere l'accesso amministrativo ad alcuni dei tuoi utenti mentre controlli e controlli cosa fanno sui tuoi sistemi, usi sudo. Tuttavia, anche con sudo, ci sono alcuni problemi invisibili: basti pensare a concedere l'accesso alla shell. I recenti rilasci di sudo hanno aggiunto funzionalità che ti consentono di vedere questi problemi e persino di controllarli. Ad esempio, puoi attivare messaggi di registro più dettagliati e più facili da elaborare e registrare ogni comando eseguito in una sessione di shell.

Alcune di queste funzionalità sono nuove di zecca. Alcuni di essi si basano su funzionalità introdotte nella versione 1.9.0 o anche precedenti. Ad esempio, sudo potrebbe registrare tutto ciò che accade su un terminale, anche nella versione 1.8. Tuttavia, il sistema memorizzava queste registrazioni localmente ed erano facili da eliminare, soprattutto quelle in cui le registrazioni erano più utili: le sessioni Shell. La versione 1.9.0 ha aggiunto la raccolta di registrazioni della sessione centrale, quindi le registrazioni non possono essere cancellate dall'utente locale, e le versioni recenti hanno aggiunto relè, rendendo la raccolta ancora più solida.

Se conosci solo le basi di sudo o hai utilizzato solo la versione 1.8 in precedenza, ti consiglio di leggere il mio articolo precedente.

1. Registrazione in formato JSON

La prima nuova funzionalità che desidero introdurre è la registrazione in formato JSON. Sono un fanatico del logging (ho iniziato a lavorare sul progetto syslog-ng dodici anni fa), e questa funzionalità è la prima introdotta dopo il mio articolo su Opensource.com. Quando abilitato, sudo registra molte più informazioni e lo fa in un modo più semplice da analizzare.

I tradizionali messaggi syslog di sudo sono brevi e contengono solo la quantità minima di informazioni necessarie. Ciò è dovuto ai vincoli delle vecchie implementazioni syslog: i messaggi di dimensioni superiori a 1k venivano scartati o troncati:

Jan 28 13:56:27 localhost.localdomain sudo[10419]: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

Le implementazioni syslog più recenti possono gestire dimensioni dei messaggi molto più grandi. syslog-ng accetta per impostazione predefinita messaggi di log fino a 64k di dimensione (ma ovviamente può essere più piccolo o più grande, a seconda della configurazione effettiva).

Lo stesso evento contiene molte più informazioni se registrato in formato JSON. Di più non significa più difficile da gestire: i messaggi in formato JSON sono più facili da analizzare da molte applicazioni software di gestione dei log. Ecco un esempio:

Jan 28 13:58:20 localhost.localdomain sudo[10518]: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-b239-469d-60ee-deb5af8ce6","server_time":{"seconds":1643374700,"nanoseconds":222446715,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submit_time":{"seconds":1643374700,"nanoseconds":209935349,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}

Puoi abilitare i messaggi di log in formato JSON nel file sudoers:

Defaults log_format=json

Puoi scoprire di più su come lavorare con i messaggi di log in formato JSON da sudo nel mio blog syslog-ng.

2. Raccolta dei log centralmente utilizzando sudo_logsrvd

Un'altra funzionalità relativa alla registrazione nella versione 1.9.4 è la raccolta di tutti i messaggi di registro sudo (inclusi gli errori) utilizzando sudo_logsrvd. In precedenza, il sistema registrava solo le sessioni riuscite quando sudo_logsrvd effettuava effettivamente una registrazione. Alla fine, la registrazione viene comunque eseguita tramite syslog per impostazione predefinita.

Perché questo è importante? Prima di tutto, puoi raccogliere tutto ciò che riguarda sudo in un unico posto: sia le registrazioni della sessione che tutti i messaggi di registro corrispondenti. In secondo luogo, può anche garantire la corretta registrazione di tutti gli eventi relativi a sudo, poiché sudo può rifiutarsi di eseguire i comandi se sudo_logsrvd è inaccessibile.

Puoi abilitare la registrazione su sudo_logsrvd con la seguente impostazione nel file sudoers (ovviamente, sostituisci l'indirizzo IP):

Defaults log_servers=172.16.167.150

Se desideri messaggi di log in formato JSON, hai bisogno della seguente impostazione nella sezione [eventlog] della configurazione sudo_logsrvd:

log_format = json

Altrimenti, sudo_logsrvd utilizza il tradizionale formato di registro sudo con una semplice modifica: include anche informazioni sull'host da cui proviene il registro:

Nov 18 12:40:16 centos8splunk.localdomain sudo[21028]:   czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Nov 18 12:40:23 centos8splunk.localdomain sudo[21028]:   czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
Nov 18 12:40:30 centos8splunk.localdomain sudo[21028]:   czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

3. Relè

Quando originariamente introdussero sudo_logsrvd (versione 1.9.0) per la raccolta delle registrazioni della sessione centrale, i client potevano solo inviare direttamente le registrazioni. La versione 1.9.7 ha introdotto il concetto di relè. Con i relè, invece di inviare direttamente le registrazioni, puoi inviare le registrazioni a più livelli di host intermedi, che strutturano la tua rete.

Perché questo è importante? Innanzitutto, i relè consentono di raccogliere le registrazioni delle sessioni anche se l'host centrale non è disponibile a causa di problemi di rete o manutenzione. Per impostazione predefinita, sudo rifiuta di essere eseguito quando non può inviare registrazioni, quindi i relè possono garantire che tu possa utilizzare sudo 24 ore su 24.

In secondo luogo, ti consente anche di avere controlli più severi sulla tua rete: invece di aprire il firewall per tutti gli host al sudo_logsrvd centrale, devi solo consentire il passaggio del tuo relè.

Infine, ti consente di raccogliere registrazioni di sessioni da reti senza accesso diretto a Internet, come le reti private AWS, dove puoi installare sudo_logsrvd in modalità relè sull'host gateway.

Quando usi i relè, la configurazione dei client sudo e del sudo_logsrvd centrale rimane la stessa. Sull'host di inoltro, aggiungi la seguente riga alla sezione [relay] di sudo_logsrvd.conf:

relay_host = 172.16.167.161

Se la connessione di rete verso il server centrale risulta problematica, è possibile configurare il relè per archiviare le registrazioni prima di inoltrarle:

store_first = true

4. Sottocomandi di registrazione

Hai mai desiderato sapere cosa succede all'interno di una sessione di shell avviata tramite sudo? Sì, ci sono le registrazioni delle sessioni, ma guardare ore di registrazioni solo per vedere un paio di comandi eseguiti è noioso e un'enorme perdita di tempo. Fortunatamente, la versione 1.9.8 ha introdotto i sottocomandi di registrazione. Ora è sufficiente controllare regolarmente i messaggi di registro e guardare le registrazioni solo quando si verifica qualcosa di sospetto.

Non hai nemmeno bisogno di una regola per consentire l'accesso alla shell, basta accedere a un editor. La maggior parte degli editor può eseguire comandi esterni. Il mio editor preferito è JOE, e questo è ciò che puoi vedere quando lo avvio tramite sudo:

Aug 30 13:03:00 czplaptop sudo[10150]:   czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe

Niente di interessante, solo un editor, anche se creo una shell ed elimino alcuni file e partizioni da quella shell. Ora vediamo cosa succede quando abiliti i sottocomandi di registrazione:

Aug 30 13:13:14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
[...]
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\]):@\1\n@g;H;x;s@/\n@\n@
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
Aug 30 13:13:42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
Aug 30 13:13:56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/

Ho omesso decine di righe per risparmiare spazio, ma puoi comunque vedere che ho avviato una shell e che i comandi eseguiti da bash_profile sono disponibili anche nei log.

Puoi abilitare i sottocomandi di registrazione nel file sudoers utilizzando la seguente impostazione:

Defaults log_subcmds

Nei tradizionali log sudo, puoi vedere dall'id del processo sudo che questi log provengono dalla stessa sessione sudo. Se attivi la registrazione in formato JSON, come mostrato in precedenza, sudo registra molte più informazioni nei log, rendendone più semplice l'analisi.

5. Intercettare i sottocomandi

I sottocomandi di registrazione rimuovono la maggior parte delle aree problematiche nascoste da sudo, ma ci sono situazioni in cui non vuoi solo guardare cosa sta succedendo ma anche controllare il flusso degli eventi. Ad esempio, devi concedere l'accesso alla shell a un utente ma vuoi comunque impedirgli di eseguire un comando specifico. L'intercettazione è l'ideale in questi casi. Ci sono, ovviamente, alcune limitazioni, ad esempio non puoi limitare i comandi incorporati delle shell.

Diciamo che il comando who è pericoloso. Puoi abilitare l'intercettazione in due passaggi: il primo la abilita, il secondo la configura. In questo caso, al mio utente non è consentito eseguire who:

Defaults intercept
czanik ALL = (ALL) ALL, !/usr/bin/who

Ecco cosa succede quando avvio una sessione della shell root tramite sudo e provo a eseguire who:

$ sudo -s
# who
Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
bash: /usr/bin/who: Permission denied

Puoi facilmente disabilitare del tutto le shell in esecuzione:

Defaults intercept
Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
czanik ALL = (ALL) ALL, !SHELLS

Tuttavia, ciò significa anche che non è possibile avviare sessioni di shell tramite sudo. Non solo, ma non puoi nemmeno eseguire comandi esterni dagli editor. Questo è ciò che accade quando provo ad avviare il comando ls da vi:

$ sudo vi /etc/issue
Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
Cannot execute shell /bin/bash
Press ENTER or type command to continue

Cosa c'è dopo?

Spero che la lettura del mio articolo ti faccia venir voglia di provare tu stesso queste nuove funzionalità. Puoi installare l'ultimo sudo su molte distribuzioni Linux e varianti UNIX dal tuo gestore pacchetti oppure utilizzare un programma di installazione binario disponibile sul sito web Sudo.

Questo articolo fornisce solo una panoramica delle nuove possibilità. Se desideri saperne di più su queste funzionalità, visita il sito Web, che ospita pagine di manuale e anche il blog Sudo.