Sapevate che systemd, oltre ad essere il PID 1 dei moderni sistemi Linux, offre anche la possibilità di proteggere i servizi? In questa mini guida illustreremo come effettuare una rapida revisione della sicurezza dei servizi e come migliorare la sicurezza.

Il principio della funzionalità di analisi di systemd è quello dell’accesso al kernel Linux, che può filtrare e limitare l’accesso a file system, alle reti, ai dispositivi, alle chiamate di sistema e altro ancora.

Una nota importante: lo strumento di revisione della sicurezza del servizio systemd è stato aggiunto dalla versione 240, ed è questa la minima versione che serve per seguire questa guida. Se avete per esempio Fedora 33, potrete verificare tutto.

systemd-analyze

Eseguendo il comando systemd-analyze security si ottiene un audit di sicurezza di tutti i servizi di systemd:

$ systemd-analyze security --no-pager
UNIT                                         EXPOSURE PREDICATE HAPPY
ModemManager.service                              5.8 MEDIUM    😐    
NetworkManager.service                            7.8 EXPOSED   🙁    
systemd-journald.service                          4.4 OK        🙂    
...    
httpd.service                                     9.2 UNSAFE    😨
...

Nell’elenco troviamo tutte le unit di systemd con associato un punteggio di sicurezza, da 0 a 10. Punteggi bassi significano servizi più sicuri. Il punteggio di sicurezza si basa sull’utilizzo da parte di un servizio delle funzionalità di sicurezza fornite da systemd.

Nota: questo audit non considera le funzionalità di sicurezza integrate nel servizio stesso o altri controlli tipo SELinux e non valuta i fattori di rischio di un programma o la sua configurazione.

Dal risultato vediamo che il servizio httpd (Apache HTTP Server) rispetto agli altri ha un punteggio superiore (quindi è più insicuro). Questo perché Fedora Linux, dove è stato effettuato il test, fornisce una unit di servizio httpd con alcune direttive di systemd, che toccano l’aspetto sicurezza, abilitate in maniera predefinita.

Ecco quindi come rivedere le direttive sulla sicurezza di un servizio.

Analisi del servizio specifico

Eseguendo il comando systemd-analyze security httpd.service otteniamo un report delle direttive di sicurezza applicate alla unit httpd.service, riassunto in questo schema:

Possiamo notare che Apache HTTP Server è limitato alla propria directory temporanea e che non ha accesso alla directory system /tmp. Questa è una politica predefinita per httpd su Fedora Linux. Chiaramente i risultati potrebbero essere diversi a seconda della distribuzione Linux utilizzata.

I risultati di audit ci mostrano come ci sia molto spazio per migliorare, a seconda della configurazione del server Apache. Ad esempio, potrebbe non necessitare dell’accesso in scrittura alla maggior parte delle posizioni nella gerarchia di file.

Vediamo quindi come rafforzare sicurezza di httpd.service.

Unit hardening

Eseguendo il comando systemctl edit httpd.service sarà possibile aggiungere delle override alla unit di servizio httpd in maniera istantanea e dinamica, ma è possibile anche modificare le unit con il proprio editor di testo preferito. I path delle stesse si possono ottenere con questo comando:

$ systemd-analyze unit-paths 
/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/usr/local/lib/systemd/system
/usr/lib/systemd/system
/run/systemd/generator.late

Sotto riportiamo come dovrà apparire l’override della unit httpd con la lista dei parametri da applicare alla unit httpd che risolve alcuni dei punti identificati nell’audit di sopra. Sarà possibile far riferimento alla pagina man systemd.exec per avere un’ampia documentazione per ogni direttiva:

$ cat /etc/systemd/system/httpd.service.d/override.conf
[Service]
PrivateDevices=true
ProtectControlGroups=true
ProtectHome=true
ProtectKernelTunables=true
ProtectSystem=full
RestrictSUIDSGID=true

Una volta salvate quindi le modifiche, basterà eseguire il comando systemctl daemon-reload per rendere systemd consapevole delle aggiunte e lanciare systemctl restart httpd.service per renderle effettive.

A questo punto una nuova analisi dimostrerà come le modifiche apportate abbiano migliorato lo stato del servizio:

$ systemd-analyze security --no-pager | grep httpd
httpd.service                                     9.2 EXPOSED    🙁

Ben lungi dall’essere ottimale, ma certamente un netto miglioramento.

Conclusioni

systemd consente di proteggere i servizi che gestisce, compensando i limiti delle installazioni di default presenti nelle distribuzioni, forniti in alcuni casi con poca o nessuna protezione. Le esigenze di sicurezza variano da installazione a installazione, quindi spetta all’amministratore di sistema abilitare le protezioni di sicurezza necessarie.

Non sarà quindi sempre necessario applicare tutte le direttive di sicurezza offerte da systemd, così come raggiungere un valore basso per ogni servizio potrebbe risultare proibitivo. Come sempre vale la regola del buonsenso: le giuste precauzioni per i giusti ambiti.