Implicazioni sulla sicurezza di avere i file di proprietà dell'utente apache?

Question

Implicazioni sulla sicurezza di avere i file di proprietà dell'utente apache?

#1 da (10 voti)
#2 da (9 voti)

14

Attualmente è in esecuzione un'istanza LAMP che gli sviluppatori stanno utilizzando per una varietà di applicazioni web. Ho il seguente scenario:

Più sviluppatori hanno bisogno di accedere per creare e modificare file in / var / www / html
Gli sviluppatori devono essere in grado di accedere al codice degli altri nel caso in cui siano in vacanza, malati, ecc.

I miei pensieri erano i seguenti:

Per ogni applicazione Web (directory) in / var / www / html, cambia ricorsivamente il proprietario in "apache" e il gruppo in un gruppo "sviluppatori". Imposta le autorizzazioni su 570 .
Per ogni file in / var / www / html, cambia ricorsivamente il proprietario in "apache" e il gruppo in un gruppo "sviluppatori". Imposta le autorizzazioni su 470 .

Mantenere i file e le directory come di sola lettura per l'utente Apache è una buona pratica di sicurezza, ma il fatto che tali file siano di proprietà dell'utente Apache non è valido? La mia preoccupazione riguardava cosa sarebbe successo se Apache fosse stata colpita da una vulnerabilità di 0 giorni o qualcosa del genere.

Se qualcuno ha un modo più elegante per farlo, mi interessa anche ascoltarlo.

permissions apache hardening

posta am4 14.12.2011 - 17:10

fonte

2 risposte

Leggi altre domande sui tag permissions apache hardening

Sali password e casualità Che cosa dovrei sapere su SPDY prima di abilitarlo?

score 10 · Answer 1

Limita il daemon con MAC

Indipendentemente da come lo si taglia, avvolgere Apache in un controllo di accesso obbligatorio come AppArmor o SELinux è un buon primo passo. Ciò ti consentirà di limitare le operazioni consentite del daemon anche se altrimenti ha le autorizzazioni per farlo. Ciò impedirà a Apache di modificare i tuoi file.

Usa il controllo della versione con i checkout automatici

Se ogni sviluppatore ha accesso a git e il ramo di produzione viene automaticamente controllato dal server Web quando viene aggiornato, si avrà il controllo e la cronologia di tutto ciò che viene caricato così come la verifica istantanea che tutto è ciò che dovrebbe essere .

Permessi

Lo svantaggio di rendere Apache il proprietario dei file è che Apache potrebbe teoricamente escludere quei file. Per questo motivo, rendere la directory dei dati e i file all'interno di proprietà di un altro utente ha un vantaggio a meno che non si aspetti che Apache modifichi la directory. Se lo fai, prova a separare le directory per contenuti e contenuti dinamici previsti che Apache non dovrebbe mai aggiornare.

score 9 · Answer 2

Hai assolutamente ragione, mantenendo l'utente in esecuzione il processo webserver, nel tuo caso apache isolato dalla scrittura sul webroot è una buona idea. È una delle guide di base per un motivo. Se l'utente può scrivere su file o directory, rende più facile per un utente malintenzionato modificare il filesystem. Una cosa che non stai prendendo in considerazione è come funziona la proprietà dei filesystem.

L'utente che possiede un file può sempre scrivere su di esso. Questo sembra contraddittorio, ma è presente in modo che l'utente possa fare cose come sovrascrivere o cancellare il file.

Se, per il tuo processo aziendale, gli sviluppatori richiedono un accesso diretto in scrittura ai file web in diretta, modifico i tuoi consigli in questo modo:

I miei pensieri erano i seguenti:

Per ogni applicazione web (directory) in /var/www/html , cambia ricorsivamente il proprietario in un altro account come nobody o root e il gruppo in un gruppo developers . Imposta le autorizzazioni su 575.
Per ogni file in /var/www/html , cambia ricorsivamente il proprietario in un altro account, ad esempio nobody o root e il gruppo in un gruppo developers . Imposta le autorizzazioni su 474.

Ciò consentirà all'utente apache di leggere i file, consentendo in tal modo a httpd di servire i file, impedendo al tempo stesso di modificare i file.