Hardening dei servizi systemd: cosa non ti dice il punteggio di esposizione

Esegui systemd-analyze security su una macchina qualsiasi e ottieni una tabella di servizi con un numero accanto a ciascuno. Viene la tentazione di leggere quel numero come un verdetto. La pagina di manuale dice, con parole insolitamente dirette, che non lo è.

Cosa misura davvero il comando

systemd-analyze security ispeziona le impostazioni di sicurezza e di sandboxing delle unità di servizio. Se gli si passa il nome di una unità, mostra un’analisi dettagliata; se non gliene si passa nessuno, ispeziona tutte le unità di servizio a lunga esecuzione attualmente caricate e stampa una tabella sintetica.

Assegna a ogni impostazione rilevante un exposure level (livello di esposizione) numerico, poi calcola un valore complessivo per l’unità. La documentazione lo descrive come «una stima nell’intervallo 0.0…10.0 che indica quanto un servizio sia esposto dal punto di vista della sicurezza». I valori alti significano che è stato applicato pochissimo sandboxing. I valori bassi significano sandboxing stretto e restrizioni forti.

Fin qui sembra uno scanner. La parte importante è l’avvertenza che segue.

I tre limiti che il manuale dichiara apertamente

Vede solo ciò che systemd stesso implementa. La documentazione è esplicita: il comando «analizza soltanto le funzioni di sicurezza per servizio che systemd stesso implementa», il che significa che «qualsiasi meccanismo di sicurezza aggiuntivo applicato dal codice del servizio stesso non viene considerato». Un servizio che rilascia i privilegi internamente, si mette da solo in un chroot o applica un proprio filtro seccomp non riceve alcun credito.

Un punteggio alto non significa vulnerabile. Questa frase merita di essere citata per intero, perché è quella che tutti saltano: un exposure level alto «non significa né che non ci sia un sandboxing efficace applicato dal codice del servizio stesso, né che il servizio sia effettivamente vulnerabile ad attacchi remoti o locali». Quello che indica è che il servizio «potrebbe trarre beneficio da impostazioni aggiuntive».

Le singole impostazioni possono essere annullate. Il manuale avverte che molte impostazioni di sandboxing «individualmente possono essere aggirate» se non vengono combinate con altre. Porta un caso concreto: un servizio che conserva il privilegio di creare o annullare punti di mount può disfare dal proprio codice molte delle altre opzioni di sandboxing. Lo strumento tiene conto di alcune di queste relazioni, ma la documentazione dice chiaramente che non le considera tutte.

Perché «combinate» è la parola che conta

Vale la pena soffermarsi sull’esempio dei punti di mount, perché cambia il modo in cui dovresti leggere i tuoi risultati.

Se una unità può manipolare i punti di mount, allora le restrizioni espresse come visibilità del filesystem possono essere potenzialmente ribaltate dal servizio stesso. La restrizione resta comunque dichiarata, e il punteggio continua a contarla, ma il suo valore pratico dipende dalla presenza di un’altra impostazione accanto a essa.

Ecco perché l’approccio a lista di controllo produce risultati deludenti. Scegliere le tre direttive che abbassano il punteggio più in fretta può lasciare una configurazione che ottiene un buon punteggio e tiene male. La conclusione della documentazione stessa è che ogni servizio dovrebbe usare «le impostazioni di sandboxing e di sicurezza più complete e più severe possibili», e non una selezione di esse.

Come usare il punteggio senza fraintenderlo

Una lettura praticabile, coerente con ciò che il manuale rivendica per lo strumento:

Trattalo come un inventario, non come un audit. Ti dice quali protezioni a livello di systemd sono assenti. Questo è davvero utile ed è poco costoso da ottenere. Non ti dice se un servizio è sicuro.

Confrontati con te stesso nel tempo. L’uso più affidabile è il rilevamento delle regressioni: una unità il cui exposure level sale dopo un aggiornamento di pacchetto o una modifica di configurazione merita un’indagine. Quel confronto è significativo anche se il numero assoluto non è un verdetto.

Non classificare i servizi di terze parti in base al punteggio. Due servizi con lo stesso numero possono avere un’esposizione reale molto diversa, perché lo strumento non può vedere il sandboxing che uno dei due applica internamente. Ordinarli per punteggio premierebbe chi dichiara di più e punirebbe chi fa di più.

Parti dalle unità che sono davvero raggiungibili. Un servizio esposto in rete con un exposure level alto è una cosa ben diversa da un timer locale con lo stesso numero. Il punteggio non sa quale sia quale, e tu sì.

Il riepilogo onesto

systemd-analyze security è un buono strumento che descrive se stesso con esattezza, cosa più rara di quanto dovrebbe essere. Misura il sandboxing a livello di systemd che hai dichiarato, su una scala da 0 a 10, e dice esplicitamente che un numero alto non è un riscontro di vulnerabilità e un numero basso non è un certificato di buona salute.

Usalo per trovare le protezioni mancanti e per intercettare le regressioni. Combina le impostazioni invece di scegliere quelle che costano meno, dato che il manuale avverte che le restrizioni isolate possono essere annullate dall’interno del servizio. E tieni presente che il numero descrive la tua configurazione, non la tua superficie di attacco.

Per lo strato sottostante a questo, la nostra guida all’hardening di Linux copre i parametri del kernel, sysctl e il controllo di accesso obbligatorio.

La descrizione del comando, l’intervallo di esposizione da 0.0 a 10.0, i tre limiti dichiarati e l’esempio dei punti di mount sono tratti dalla pagina di manuale di systemd-analyze così come viene distribuita con systemd 255. La formulazione e il comportamento possono cambiare tra le versioni di systemd; consulta il manuale della versione che stai usando. Questo articolo non include alcun esempio di output del comando, perché l’ambiente usato per scriverlo non esegue systemd come PID 1, e inventarne uno avrebbe travisato un risultato reale.