Scenari di protezione delle autorizzazioni per un server Web

Question

Scenari di protezione delle autorizzazioni per un server Web

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

2

Avendo /var/www/site.com di proprietà di www-data:www-data con un'autorizzazione di 750 per le directory e 640 per i file e avendo il mio utente alexb aggiunto a www-data group, ho trovato me stesso con i problemi di autorizzazione quando provo a estrarre nuovi rilasci ( git pull ) all'ambiente di test.

Quindi, al momento, le uniche soluzioni che mi vengono in mente sono le seguenti:

alexb:www-data ownership per /var/www/site.com con gli stessi 750 e 640
Attacca a www-data:www-data e a un layout di autorizzazioni 750 e 640.
Crea un nuovo utente e gruppo (staging-user: staging-group), assegna a quel nuovo utente l'accesso reale alla shell e assegna la proprietà di /var/www/site.com a loro, con il layout iniziale delle autorizzazioni 750 e 640, in modo che quando Ho bisogno di eseguire le azioni di shell ( git pull per esempio), ho appena cambiato utente e lo faccio.

Ora le domande sono:

Qual è il peggiore?
Qualche cosa che potrei perdere?

linux permissions

posta w0rldart 11.08.2014 - 19:13

fonte

3 risposte

Leggi altre domande sui tag linux permissions

Quanto è rischioso avere file sensibili su webroot? Qualcuno ha usato il mio router per configurare la propria rete

score 3 · Answer 1

Having /var/www/site.com owned by www-data:www-data

Se www-data è anche l'uid che il tuo server web esegue come se avessi un sistema davvero insicuro. Il server web dovrebbe avere solo accesso in lettura (ed eseguito per le directory). Se è necessario consentire al server Web di scrivere i dati, questa directory dovrebbe essere ringfenced e preferibilmente al di fuori della root dei documenti.

Se alexb è l'unico account che richiede l'accesso in scrittura, allora "alexb: www-data ownership per /var/www/site.com con gli stessi 750 e 640" è un approccio ragionevole. Tuttavia, se si hanno più utenti che necessitano dell'accesso in scrittura, la soluzione migliore è probabilmente creare un nuovo gruppo con tale accesso, consentire al server di lettura l'accesso come "altro" (775/664), ma ricordarsi di impostare le umask dell'utente in modo appropriato (e abilita il bit setgid sulla directory (2775)

score 1 · Answer 2

xx4 nella cartella è più come avere xx0 , poiché "gli altri" non saranno in grado di vedere il contenuto di quella directory. Vederanno la cartella, ma non potranno farci niente.

Poiché il server web probabilmente non ha bisogno di permessi di scrittura, userei alexb:www-data con 750 (directory) e 640 (file), in questo modo riduce i privilegi per il web server ma ti permette di usare il tuo utente personale senza preoccuparti troppo.

A parte questo, dovresti impostare tutte le cartelle g+s permessi, quindi anche nel caso in cui tu crei file come alexb dell'utente, il server web avrà comunque accesso attraverso le autorizzazioni del gruppo (presumo che il tuo utente alexb non ha www-data come suo gruppo principale, quindi l'utilizzo di tale autorizzazione manterrebbe l'ID di gruppo attraverso i nuovi file).

Ricordati di impostare il tuo UMASK in modo appropriato (come 027 ), e fai non usa /var/www/site.com come directory home dell'utente.

Inoltre, prendi in considerazione sistemi di sicurezza come SELinux (RedHat, CentOS e simili).

score 1 · Answer 3

Manca l'opzione degli ACL. Linux ha un sistema ACL molto flessibile che la maggior parte delle persone non considera. Ho scritto un post di questo blog qualche tempo fa:

link

In genere, ho impostato la proprietà e il gruppo per l'utente della shell e qualsiasi gruppo di utenti interattivi che devono essere in grado di aggiornare tali file.

Quindi utilizzo lo script grant-apache-read per consentire al web server di accedervi:

source ~/lib/acl.bash; grantUserRead 'www-data' /var/www/site.come '*';

Due cose che dovrai ricordare quando provi questo:

Devi assicurarti di aver installato setfacl
Assicurati che l'utente corretto venga passato alla funzione
Avrai bisogno dello ~ / lib / acl.bash script
Ho anche creato uno script grant-apache-write per le directory cache e log