Sto cercando di capire quali permessi sono consentiti da alcuni dei booleani di SELinux per il dominio httpd, poiché è la mia principale fonte di preoccupazione e l'attuale politica della mia organizzazione è di dare veramente il minimo privilegio richiesto per ottenere un applicazione funzionante.
Leggendo con sesearch cosa fanno alcuni booleani, è chiaro che non ne ho davvero bisogno, quindi li abbiamo disabilitati. Ad esempio, non abbiamo bisogno che nginx sia in grado di connettersi alle porte squid, ftp, gopher e memcache, tra le altre cose il permesso booleano httpd_can_network_relay , perché passiamo le nostre richieste tramite socket. Booleano httpd_can_network_connect è troppo ampio per noi, poiché l'unica porta di cui abbiamo bisogno è aperta, è già etichettata per i redis e abbiamo un modulo di policy molto facile da capire per questo: link
Ho faticato un po 'a far funzionare alcuni script PHP, anche dopo aver etichettato attentamente alcuni percorsi pubblici, al fine di consentire solo le scritture dalla webapp su upload e cache per le directory captchas, ma non lasciare magicamente quell'aggiornamento da solo o scaricare da script di terze parti che potrebbero essere eseguiti. Inoltre, è sufficiente consentire l'esecuzione di script in percorsi specifici.
Ho già realizzato questo obiettivo e le persone esterne all'IT stanno lavorando senza lamentarsi, ma non riesco ancora a capire completamente ciò che i booleani che ho dovuto abilitare stanno permettendo, perché le pagine man sono utile per abilitare rapidamente qualcosa ma non capire come funziona magic . E l'output di sesearch è troppo confuso.
Ad esempio: sesearch -AC -b httpd_anon_write indica che solo le scritture in public_content_rw_t sono etichettate, ma non capisco perché non ha funzionato con httpd_sys_content_rw_t .
Ma l'output di booleans httpd_unified e httpd_builtin_scripting è in conflitto, e sono francamente preoccupato di consentire senza troppe cose. Specialmente sugli oggetti con httpd_sys_rw_content_t non sono riuscito a far funzionare le scritture senza abilitare entrambi i booleani e non ho attivato httpd_enable_cgi perché le autorizzazioni sembrano essere larghe per me. Guarda la parte più confusa:
DT allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
ET allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_builtin_scripting ]
Forse è che non capisco dove è il AND e se c'è un OR , ma non capisco perché tutte le operazioni siano consentite secondo la precedente regola , abilitando solo httpd_builtin_scripting , e perché secondo la prima regola, deve essere abilitato lo stesso booleano, AND httpd_unified AND httpd_enable_cgi .
Onestamente sarei più che felice di non dipendere da nessun booleano che permetta più di quello che è strettamente necessario, ecco perché sarei grato di ottenere una mano aiutandomi a capire la sintassi dei booleani necessari per una regola essere abilitato.
FWIW, la webapp che sto proteggendo è basata su WordPress, e le esercitazioni in giro dipendono dai booleani senza spiegare perché sono necessari e quali rischi introducono. La mia organizzazione ha un brutto disgusto per gli aggiornamenti automatici anche per le interruzioni di compatibilità.