Insidie nell'utilizzo di SELinux per i server LAMP

Se la regressione ha testato tutto e non ha riscontrato problemi insormontabili, allora è grandioso, tuttavia la mia esperienza è opposto di TorstenS - Penso che si traduca in una diminuzione netta della sicurezza del tuo sistema, tranne negli scenari specifici (e" il server LAMP "difficilmente rientrerà in quella categoria) elencato nel post collegato.

Riassumendo: complessità, opacità dell'astrazione e scarsa documentazione rendono molto difficile comprendere l'implementazione e adattarla a scopi specifici. Ci sono poche prove che anche un'installazione configurata con competenza sia più sicura di un sistema che non applica una politica. Sebbene intrinsecamente sia improbabile aumentare la superficie di attacco, è probabile che risolvendo la funzionalità un impatto sulle prestazioni che introduce (cioè compromettendo la politica commerciale fornita dal fornitore) minerà la sicurezza generale del sistema in modi che non capisco.

Come dice schroeder, è troppo ampio. Tuttavia mi piacerebbe aggiungere due bit di confronto concreto dei plug-in setroubleshoot che forniscono cattivi indizi sulla sicurezza.

Primo esempio, il web server delle porte di rete può connettersi. Ho impostato redis come archivio di sessioni piuttosto che come file per PHP. Preferisco connettermi tramite la porta TCP piuttosto che il socket. Pertanto, il consiglio fornito da sealert è di attivare httpd_can_network_connect booleano. Ma è meglio consentire solo la porta specifica, in questo caso, redis_port_t , e non ogni porta:

module httpd_connect_redis 1.0.0;

require {
    class tcp_socket { name_connect };
    type httpd_t;
    type redis_port_t;
}

allow httpd_t redis_port_t:tcp_socket name_connect;

Secondo esempio, un caso tristemente non raro di Plesk che configura Apache e NginX da eseguire in tandem, con il primo come proxy inverso. Plesk configura Apache per l'esecuzione sulle porte 7080 e 7081, senza riservare le stesse porte in una politica personalizzata, non parliamo adesso di impostare i binari php-fpm come servizi non confinati (Bad Plesk, molto male).

Se seguissi il consiglio di setro per la risoluzione dei problemi, consentirei NginX name_connect a qualsiasi porta non riservata, o qualsiasi altra porta che abiliti% booleano% e, non solo 7080 e 7081. Invece, è stato un po 'più di lavoro, ma come nel caso della porta redis, ho creato un tipo personalizzato per taggare le due porte, e quindi chiudere i messaggi di controllo, perché non sto proprio usando Apache per eseguire le mie webapps e semplicemente usare Plesk perché il mio capo pensa è un modo in cui può vedere come sono configurati i domini. Ad ogni modo, non è difficile scrivere una policy di base per creare etichette personalizzate per le porte personalizzate e impostare solo le autorizzazioni necessarie e non aprire tutto rapidamente come consentito dai booleani, ma eseguire tutto senza restrizioni non è meglio che avere SELinux disabilitato.

module plesk_disallowed_apache_proxy 1.1.0;

type plesk_apache_behind_proxy_port_t;
require {
    class tcp_socket { name_connect name_bind };
    attribute port_type;
    type httpd_t;
}
typeattribute plesk_apache_behind_proxy_port_t port_type;

dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_connect;
dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_bind;

Dovresti essere consapevole che abilitare SELinux rende potenzialmente il tuo Server più sicuro di quanto sarebbe se fosse disabilitato. Ma non è mai un "one click hardening".