Questa serie di articoli esplorerà alcune delle mie funzionalità preferite di Red Hat Enterprise Linux (RHEL) 8 abilitate da systemd . Pertanto, questa serie presuppone familiarità con i concetti di base di systemd . Se hai bisogno di una buona introduzione, c'è un'ampia documentazione sul prodotto sia sul Red Hat Customer Portal che sul sito del progetto. In alternativa, su YouTube sono disponibili diverse presentazioni per tenerti aggiornato prima di continuare.
Systemd fornisce un numero significativo di funzionalità di sicurezza che possono essere utilizzate per isolare servizi e applicazioni l'uno dall'altro, nonché dal sistema operativo sottostante. In molti casi, systemd fornisce un facile accesso agli stessi meccanismi forniti dal kernel Linux utilizzati anche per creare l'isolamento per i container Linux. Avere la capacità di fornire un isolamento in stile container per applicazioni e servizi tradizionali è potente perché ora è facile migliorare la sicurezza e l'isolamento dei carichi di lavoro senza l'impatto operativo richiesto dai container. Vale la pena notare che i cambiamenti operativi e organizzativi ispirati dall'adozione dei container sono davvero salutari e utili. Tuttavia, anche nelle aziende più esperte di container, esiste un gran numero di implementazioni Linux tradizionali in cui la sicurezza è una priorità assoluta. Come vedremo, i carichi di lavoro su questi sistemi possono trarre vantaggio da poche modifiche ai file di unità corrispondenti.
Opzioni di sicurezza comuni a Red Hat Enterprise Linux 7 e 8
La maggior parte delle opzioni esplorate di seguito accetta un binario true o false configurazione che li rende facili da abilitare. Ce ne sono alcuni che contengono opzioni aggiuntive e vengono mostrate anche le più significative. Fare riferimento alla documentazione completa e alle pagine man per ulteriori dettagli. Se non ti interessa il nocciolo della questione di queste opzioni, sentiti libero di passare alla sezione successiva in cui metteremo insieme queste opzioni per esempi più coerenti:
| Opzione | Descrizione |
|---|---|
PrivateTmp=yes | Crea uno spazio dei nomi di file system in /tmp/systemd-private-*-[unit name]-*/tmp piuttosto che un /tmp condiviso o /var/tmp . Molti dei file unit forniti con Red Hat Enterprise Linux includono questa impostazione e rimuove un'intera classe di vulnerabilità relative alla previsione e alla sostituzione dei file utilizzati in /tmp . |
PrivateNetwork= | Fornisce uno spazio dei nomi di rete per il servizio con solo un'interfaccia di loopback disponibile. Un'ottima opzione per le applicazioni che non richiedono la comunicazione di rete esterna. |
SELinuxContext= | Esegue l'applicazione in un contesto specifico. Questa opzione è una buona idea per definire quando una policy è disponibile per le applicazioni spedite al di fuori di RHEL. Un buon primer per SELinux è disponibile qui. |
NoNewPrivileges= | Impedisce al servizio e ai relativi processi figlio di aumentare i privilegi. |
ProtectSystem=yes | Rende /usr e /boot sola lettura per l'applicazione. Impostando questa opzione su full fa anche /etc sola lettura. In Red Hat Enterprise Linux 8, c'è un'opzione aggiuntiva chiamata strict che rende anche /dev , /proc e /sys di sola lettura. |
ProtectHome=yes | Crea /home , /root e /run/user apparire vuoto. Un'opzione aggiuntiva è read-only , che fa esattamente quello che dice. Nuovo anche per RHEL 8, tmpfs in questi punti si sovrapporrà a un file system effimero scrivibile. Poiché queste directory vengono utilizzate per archiviare chiavi SSH e altre informazioni potenzialmente sensibili, è una buona idea vietare l'accesso alle applicazioni. |
ProtectDevices=yes | Crea un /dev privato spazio dei nomi contenente solo pseudo dispositivi come /dev/null e /dev/random , che non danno accesso all'hardware effettivo. Disabilita anche CAP_MKNOD in modo che non possano essere creati nuovi nodi dispositivo. |
CapabilityBoundingSet= | Accetta una whitelist e una blacklist di capacità privilegiate per l'unità. Le funzionalità di Linux interrompono l'accesso dell'utente root al sistema in modo che l'accesso privilegiato possa essere individuato meglio. L'esempio classico è per NTP o chrony per poter configurare l'orologio di sistema ma non eseguire altre azioni privilegiate. Maggiori dettagli sono disponibili nella pagina man delle capacità (7). |
|
| Si comporta in modo simile a ProtectSystem , ma tutte e tre queste opzioni consentono un controllo dettagliato dell'accesso al file system. |
Nuove opzioni di sicurezza in Red Hat Enterprise Linux 8
Le nuove opzioni di sicurezza del sistema disponibili in Red Hat Enterprise Linux 8 sono:
| Opzione | Descrizione |
|---|---|
ProtectKernelTunables=yes | Disabilita la modifica di /proc e /sys . |
ProtectKernelModules=yes | Proibisce il caricamento o lo scaricamento di moduli e maschere /usr/lib/modules dall'applicazione. |
ProtectControlGroups=yes | Disabilita l'accesso in scrittura a /sys/fs/cgroup/ . |
RestrictNamespaces= | Limita tutti o un sottoinsieme di spazi dei nomi al servizio. Accetta cgroup , ipc , net , mnt , pid , user e uts . |
AssertSecurity= | Richiede una serie di requisiti che devono essere soddisfatti dal sistema per l'avvio del servizio. Se le funzionalità elencate non sono disponibili, il servizio non verrà eseguito e l'evento verrà registrato. Opzioni come selinux e uefi-secureboot sono utili per molti ambienti. |
MemoryDenyWriteExecute= | Disabilita la mappatura della memoria che è contemporaneamente scrivibile ed eseguibile. |
RestrictRealtime=yes | Proibisce la pianificazione in tempo reale. |
PrivateMounts=yes | Fa in modo che il servizio venga eseguito in uno spazio dei nomi di montaggio privato. |
DynamicUser=yes | Crea effettivamente un utente transitorio per l'applicazione. Questa opzione probabilmente garantisce il proprio post per esplorare, ma brevemente, il systemd l'implementazione è brillante perché crea dinamicamente (come suggerisce il nome) un UID e un GID collegando un nss modulo che "crea" l'utente al volo. Questi utenti semplicemente non esistono quando il servizio non è in esecuzione. Questa funzione è particolarmente utile per le applicazioni stateless, ma è possibile mappare le directory in cui scrivere. |
SystemCallFilter= | Consente di inserire nella whitelist e nella blacklist singole chiamate di sistema o utilizzare i gruppi di chiamate intuitivi che systemd fornisce. Se hai familiarità con seccomp filtrando con i contenitori, questa opzione fornisce esattamente la stessa cosa. In senso generale, la maggior parte degli utenti troverà il @system-service filtro prezioso, che abilita le chiamate di sistema rilevanti necessarie per la maggior parte dei servizi. Gli utenti possono visualizzare l'elenco dei gruppi e delle chiamate di sistema disponibili eseguendo systemd-analyze syscall-filter . |
[Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente.]
Un esempio
Se sei arrivato così lontano, potresti pensare:"OK, sembra davvero potente, ma è molto da ricordare". Fortunatamente, a partire da Red Hat Enterprise Linux 8.1, abbiamo aggiunto un comando per rendere molto più semplice fare riferimento e controllare lo stato di queste opzioni:
systemd-analyze security [unit]
Questo comando genera una rapida istantanea di come il sistema sta sfruttando systemd sandboxing di e può anche visualizzare le singole impostazioni per unità. Questo design semplifica l'identificazione delle opzioni disponibili e la visualizzazione del loro utilizzo a livello granulare.
Ecco l'output del httpd.service predefinito unità:
Questo output da systemd-analyze security mostra il nome, una descrizione conveniente e una valutazione dell'esposizione, che dimostra il consumo delle impostazioni di sicurezza disponibili per servizio e genera un punteggio di esposizione ponderato da quanto è isolato il servizio. Vale la pena notare che questo strumento non ha lo scopo di fornire una visione olistica o un'opinione sulla sicurezza per il codice o l'applicazione in esecuzione sul sistema. Solo perché httpd.service ritorna come UNSAFE su un'installazione predefinita non significa che il servizio non sia sicuro.
Ora che sappiamo come interrogare le unità e vedere quali controlli sono in uso, diamo un'occhiata ad applicarli a un semplice server web. Questo esempio generico funge da facile punto di partenza per altri servizi e applicazioni.
Attiva le opzioni di sicurezza
Innanzitutto, crea un drop-in systemd per aggiungere le opzioni di sicurezza. Per Red Hat Enterprise Linux 8, eseguire:
# systemctl edit httpd
Oppure, se preferisci, crea manualmente /etc/systemd/system/httpd.service.d/security.conf .
Indipendentemente dal modo in cui hai effettuato l'accesso al file, ora aggiungi:
[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
NoNewPrivileges=yes
PrivateTmp=yes
Per Red Hat Enterprise Linux 7, possiamo utilizzare un modello simile:
[Service]
ProtectSystem=full
ProtectHome=yes
PrivateDevices=yes
NoNewPrivileges=yes
PrivateTmp=yes
Dopo aver salvato il file e riavviato il servizio, httpd il servizio sarà significativamente isolato dal resto del sistema operativo. Se il servizio viene mai compromesso, il rischio di rotture e danni conseguenti viene drasticamente ridotto.
Gli esempi precedenti sono un ottimo punto di partenza per bloccare servizi, applicazioni e unità in esecuzione sul sistema. Ovviamente dovresti testarli per assicurarti che siano appropriati per il tuo caso d'uso prima di distribuirli all'intera flotta. Ad esempio, se volessimo pubblicare contenuti dalle home directory degli utenti, non includeremmo ProtectHome=yes , ma invece, usa ProtectHome=read-only . Vale anche la pena notare che non è dannoso includere le opzioni più recenti aggiunte in RHEL 8 su un file di unità eseguito in RHEL 7. Verrà emesso un messaggio di notifica e l'opzione verrà ignorata.
Visualizza i risultati
Ora possiamo visualizzare le opzioni in uso eseguendo systemd-analyze httpd :
Puoi vedere che una serie di opzioni vengono ora applicate sul server web. Anche la valutazione è cambiata da UNSAFE a MEDIUM . Sebbene sia del tutto possibile abilitare più opzioni e bloccare ulteriormente il servizio, ci allontaneremo dall'obiettivo di fornire un esempio pratico che si applicherà con successo a molti servizi e applicazioni nel mondo reale. Mai prima d'ora è stato così semplice limitare l'accesso di un servizio tradizionale al sistema operativo sottostante.
Conclusione
Per gli sviluppatori interessati a proteggere il proprio software, le opzioni di sicurezza pertinenti possono essere facilmente aggiunte ai file unit inclusi con l'applicazione. Red Hat incoraggia vivamente gli sviluppatori a "integrare" quanta più sicurezza possibile per impostazione predefinita, e questo è uno dei modi più semplici per raggiungere questo obiettivo.
Per coloro che si chiedono se le funzionalità di sicurezza mostrate qui siano ridondanti con SELinux, c'è una sovrapposizione nella funzione ma sono in gran parte indipendenti. Queste impostazioni verranno applicate indipendentemente dal fatto che SELinux venga utilizzato o meno. Questa caratteristica è un valore enorme quando SELinux non è un'opzione praticabile a causa di criteri o requisiti applicativi per determinati sistemi. In un mondo ideale, questi sarebbero usati with SELinux come parte di un approccio alla sicurezza a più livelli.
Spero che ti sia piaciuto apprendere quanto sia facile isolare e sandbox i carichi di lavoro installati su Red Hat Enterprise Linux 8 con systemd . Ora vai avanti e, se del caso, applica questa conoscenza in tutto il tuo ambiente. Nel prossimo articolo di questa serie, esamineremo l'utilizzo dei gruppi di controllo Linux, alias cgroups , tramite systemd per proteggere preziose risorse di sistema e risolvere il problema del "vicino rumoroso".