Logica dietro SELinux che impedisce l'accesso ai file

1

Alcune delle poche volte in cui ho avuto a che fare con SELinux sono state quando ho configurato un server web locale su una scatola Fedora. I problemi si sono verificati quando un'applicazione Web ha provato a scrivere file sul file system.

Sono abituato a impostare correttamente i permessi dei file Posix, quindi uno dei primi passi che eseguo sempre è chown apache:apache -R /var/www/ . Successivamente, utilizzo solo l'utente apache per interagire con il webroot o le applicazioni Web.

Tuttavia, su Fedora, SELinux impedisce di scrivere su file. Ho seguito il consiglio dello strumento di risoluzione dei problemi di SELinux per disabilitare questa protezione, ma mi ha fatto riflettere.

Perché SELinux impedisce l'accesso in scrittura ai file per un processo (apache) quando quel processo è già in esecuzione come proprio utente, e le normali autorizzazioni dei file vecchi possono quindi essere configurate facilmente, specifiche per Apache? E ci sono altri casi d'uso che rendono (più) senso questo tipo di prevenzione dell'accesso ai file?

    
posta aross 07.03.2017 - 17:16
fonte

3 risposte

2

TL; DR

Imposta i livelli di accesso per le singole applicazioni Web.

letto

Dopo aver letto questa pagina , penso di avere una buona idea della logica. In SELinux, ogni file ha un contesto di sicurezza. Puoi visualizzare il contesto di sicurezza attuale con ls -Z <path> e impostare un nuovo contesto di sicurezza con chcon .

Tutte le app Web verranno eseguite come apache utente, quindi in circostanze normali, ogni app Web avrà le stesse autorizzazioni. Con i contesti di sicurezza, puoi limitare l'accesso a singole app / script. Per impostazione predefinita, gli script hanno accesso in sola lettura.

Questo è in realtà abbastanza utile per la sicurezza. Supponiamo che tu abbia un'applicazione di cui ti fidi, che richiede l'accesso in scrittura. Daremo esplicitamente a questo script il contesto httpd_unconfined_script_exec_t . Supponiamo ora di avere un'applicazione non sicura soggetta a exploit. Si lascerebbe il contesto di sicurezza degli script che appartengono a tale applicazione in modo predefinito, il che impedisce di scrivere file.

Prevenire le scritture di file impedirebbe un'intera gamma di attacchi che sfruttano alcune vulnerabilità per scrivere uno script su disco, che può successivamente essere eseguito su http dall'attaccante.

    
risposta data 10.03.2017 - 10:49
fonte
1

Penso che parte della risposta si riferisca a qualcosa che hai menzionato:

I'm used to setting up Posix file permissions properly, so one of the first steps I always perform is chown apache:apache -R /var/www/. Subsequently, I only use the apache user to interact with the webroot or the web applications.

Perché lo fai?

Molto probabilmente per aiutare a proteggere il tuo sistema da un processo anomalo, o scendere a compromessi.

seLinux è un altro livello / meccanismo per ottenere lo stesso risultato.

Un approccio sensato (e migliore) alla sicurezza è quello di stratificare le difese e, più in generale, di provare a utilizzare diversi mezzi per proteggere il sistema. Se si sovrappongono, grandi: i modi più diversi di proteggere la stessa cosa, più un attaccante deve lavorare per raggiungere i propri obiettivi.

L'idea di base con seLinux che impedisce la scrittura (o la lettura) è che, come con POSIX, è necessario concedere esplicitamente l'accesso a un programma che richiederà.

/var/www sarà in un gran numero di casi legittimamente di sola lettura: i siti statici sarebbero un caso ovvio. Nel tuo caso, non menzioni mai chmod 'ing / var / www, quindi molto probabilmente sarebbe 750 (o 700), e di proprietà di apache.

In tal caso, almeno seLinux ti fa pensare se quel chmod e il livello di accesso siano effettivamente necessari: a meno che tu non abbia effettivamente bisogno di scrivere file, probabilmente non lo è, e sembra ragionevole dire che seLinux aiuta infatti a evitare che funzionalità / accesso siano disponibili e non necessarie.

Ti stai concentrando sulle qualità simili a POSIX, ma seLinux ti consente anche di impedire ad apache di avviare le connessioni in uscita, ad esempio, e può limitare le connessioni in uscita consentite a un piccolo numero di porte. Personalmente, a volte trovo utile vedere le capacità di seLinux come affini a un daemon auditd che impone - si sta guardando al comportamento, e può essere molto più specifico sul comportamento accettabile, rispetto a POSIX rende possibile (in parte perché POSIX non è tanto protezione e altro sulla compatibilità e fornendo un insieme di funzionalità di base e stabile).

Potrei pagare per leggere ciò che Wikipedia ha da dire su entrambi POSIX e SELinux - e anche considerare il fatto che POSIX fornisce Controllo accessi discrezionale , dove seLinux fornisce Controllo di accesso obbligatorio .

Le differenze DAC / MAC sono un punto chiave per rispondere alla tua domanda: il MAC è generalmente un criterio a livello di sistema che è controllato centralmente (tipicamente con un occhio per garantire che un sistema funzioni correttamente), dove DAC consente decisioni locali da fare - c'è un'evidente tensione tra questi approcci, e seLinux è lì per assicurare che la politica globale venga applicata anche di fronte a decisioni locali che potrebbero minarlo.

    
risposta data 09.04.2017 - 13:12
fonte
0

I can't make sense of this file access restriction, knowing a sysadmin could just do chmod -R -w /var/www/html/

Penso che la minaccia qui non sia l'utente che cerca di accedere ai propri file, ma il programma viene sfruttato.

Immagina Firefox che cade vittima di un attacco di corruzione della memoria che consente all'utente malintenzionato di eseguire codice arbitrario: se SELinux limita l'accesso di Firefox agli unici file che deve funzionare, non può fare danni altrove, come i tuoi file personali e il resto del sistema.

Inoltre, parli di un sysadmin , che mi fa pensare che dovresti definire con maggiore precisione cosa pensi che SELinux difenda contro il sistema. L'amministratore di sistema ha accesso root per definizione e nulla può quindi impedirgli di fare qualsiasi cosa. SELinux attenua gli utenti non autorizzati e gli exploit del programma, ma non può fare miracoli.

    
risposta data 07.03.2017 - 18:20
fonte

Leggi altre domande sui tag