Quali sono le autorizzazioni unix perfette per le normali directory dei progetti Web?

Quali sono i permessi minimi perfetti in formato ottale per i seguenti in un'applicazione web scritta?

1. Una directory in cui risiedono i file statici caricati dall'utente (file images / swf / js)
2. Una directory in cui l'amministratore ha caricato i file statici (file images / swf / js)
3. Una directory in cui risiedono le librerie utilizzate nell'applicazione
4. Una directory in cui risiederanno gli script lato server eseguibili / navigabili
5. Una directory in cui i file già esistenti (txt o xml) verranno modificati dal codice sul lato server

Ecco i miei suggerimenti e giustificazioni

1. 555, tutti possono leggere e scrivere, nessuno può eseguire
2. 544, solo il proprietario può scrivere, tutti gli altri possono solo leggere, nessuno può eseguire
3. 000, nessuno ha bisogno di leggere, scrivere o eseguire, sarà utilizzato solo dal web server?
4. 661, il proprietario può leggere, scrivere, tutti gli altri possono solo eseguire
5. 600, il proprietario può leggere, scrivere (potrebbe non essere necessario), nessun altro può fare nulla

Ora sono interessato a due cose:

1. C'è qualcosa di comunemente usato nelle applicazioni web che mi è sfuggito nel primo elenco?
2. C'è qualcosa con cui non sei d'accordo nel secondo elenco, qual è la tua alternativa e perché è meglio?

Supponendo che un'applicazione Web funzioni su un server (come apache, nginx, ecc.) E sia scritta in un linguaggio di script dinamico (come PHP, Ruby, ecc.), Si ha un malinteso su chi sia l'utente.

L'utente non è la persona che ha effettuato l'accesso all'applicazione - questo e il suo ruolo nell'applicazione (amministratore, ecc.) È completamente irrilevante per lo scenario. L'utente è l'utente del sistema Linux in cui viene eseguito il processo. Il codice del tuo sito Web viene eseguito come un solo utente: potrebbe essere l'utente del tuo server web (che non è davvero una buona cosa) o potrebbe essere un utente specifico del tuo sito (che è molto meglio).

Su Linux, gli utenti appartengono a gruppi: possiamo aggiungere un utente a un altro gruppo e assegnare privilegi a quel gruppo.

Una buona configurazione farà funzionare il tuo server come un solo utente (chiamiamo questo "webserver") e il tuo linguaggio di scripting dinamico verrà eseguito (ad es. Tramite FastCGI) come proprio utente (un utente per sito - chiamiamo il nostro primo utente "site1") .

Per servire i tuoi file, il server web deve accedervi e il linguaggio di scripting deve accedervi. Ciò significa che 'site1' e 'webserver' devono essere in grado di leggere i tuoi file. Solo uno di essi, tuttavia, può "possedere" i file. Il proprietario è l '"utente" (in utente, gruppo, altro). Abbiamo anche bisogno del nostro linguaggio di scripting per poter scrivere nella directory (e leggere i file che ha scritto). L'utente "site1" pertanto necessita delle autorizzazioni di lettura e scrittura. Poiché desideriamo che le autorizzazioni di gruppo e altre siano il più restrittive possibile, il nostro "proprietario" sarà "site1" e le autorizzazioni utente corrispondenti verranno lette e scritte.

Dato che non possiamo specificare le autorizzazioni per il nostro server web come un altro "utente", aggiungeremo "server web" al gruppo "sito1" (è possibile ovviamente creare un gruppo diverso con "sito1" e "server web" al suo interno). ai membri di questo gruppo verranno assegnate le stesse autorizzazioni. Le autorizzazioni più lassiste (dell'utente, del gruppo, di altri set) verranno applicate a ciascun utente per determinarne le autorizzazioni.

Vale la pena notare che una buona installazione non dovrebbe richiedere ai file di disporre delle autorizzazioni di esecuzione per un linguaggio dinamico. I file non vengono eseguiti direttamente, ma vengono letti in un interprete: per eseguire uno script tipico sono necessari solo i permessi di lettura (uno che non scrive nulla).

L'autorizzazione "esegui" per le directory ha un significato diverso: consente l'attraversamento senza poter leggere il contenuto. Per poter leggere un file in una directory, un utente deve disporre delle autorizzazioni di "esecuzione" su OGNI directory sopra di esso.

Per un'applicazione Web, ogni file deve avere le autorizzazioni di lettura del suo proprietario, altrimenti è un file abbastanza inutile. Se un utente o un amministratore carica file (tramite l'applicazione Web), il "proprietario" (ovvero il linguaggio dinamico) necessita delle autorizzazioni di scrittura. Un'installazione efficiente proverà a servire i file statici direttamente tramite il server Web, poiché i linguaggi dinamici tendono ad essere lenti nella lettura di file di grandi dimensioni e nell'eco dei contenuti. Pertanto, il server Web necessita dell'accesso in lettura ai file statici.

Pertanto, le autorizzazioni minime per i file possono essere:

• Un file in una directory in cui l'utente ha caricato i file statici (file images / swf / js) risiederà: 640
• Un file in una directory in cui l'amministratore ha caricato i file statici (file images / swf / js) risiederà: 640
• Un file in una directory in cui risiedono le librerie utilizzate nell'applicazione: 400 (o 440)
• Un file in una directory in cui risiederanno gli script lato server eseguibili / sfogliabili: 400 (o 440)
• Un file in una directory in cui i file già esistenti (txt o xml) verranno modificati dal codice sul lato server: 640 o 600
  • (dipende dal fatto che il server Web li visualizzi, a volte non modificato)

Mentre, le autorizzazioni di directory minime possono essere:

• Una directory in cui l'utente ha caricato i file statici (file images / swf / js) risiederà: 750
• Una directory in cui l'amministratore ha caricato i file statici (file images / swf / js) risiederà: 750
• Una directory in cui risiedono le librerie utilizzate nell'applicazione: 500 (o 550) [dovrebbe essere almeno 510]
• Una directory in cui risiederanno gli script lato server eseguibili / navigabili: 500 (o 550) [dovrebbe essere almeno 510]
• Una directory in cui i file già esistenti (txt o xml) verranno modificati dal codice sul lato server: 750 o 700
  • (dipende dal fatto che il server web servirà i file da qui, a volte non modificato)

Ancora una volta - il tuo server web deve disporre delle autorizzazioni di "esecuzione" su ogni directory al di sopra di quella a cui deve accedere - quindi anche se il server web non fornirà i file da una determinata directory, dovremmo concedergli le autorizzazioni di esecuzione.

È abbastanza comune dare al server web l'accesso in lettura alla maggior parte dei file (quindi cambia quelli da 500 a 550). Le autorizzazioni predefinite "piuttosto sicure" sono generalmente 755 per le directory e 644 per i file - nessuna autorizzazione di esecuzione, tutti possono leggere e solo l'utente può scrivere - noterai che la stragrande maggioranza dei file su un sistema Linux ha queste autorizzazioni.

Tenere presente che le autorizzazioni "altro" si riferiscono a qualsiasi utente del sistema che non sia il proprietario o nel gruppo (ovvero tutti gli utenti di sistema rimanenti). Mantenere le tue "altre" autorizzazioni restrittive è un bene, perché questi utenti sono sconosciuti - non hai dato loro esplicitamente l'autorizzazione. Le altre autorizzazioni sono spesso le più facili da sfruttare su un sistema compromesso (ad esempio uno dei motivi per cui / tmp è un obiettivo comune).

Nel contesto di quanto sopra, non credo che le tue ultime due domande siano così rilevanti. Impostare le autorizzazioni per la directory su 550 (e le autorizzazioni per i file su 440), quindi concedere all'utente le autorizzazioni di scrittura per tutte le directory su cui verrà scritta l'applicazione (ovvero directory: 750; file: 640).

(Avrai ovviamente bisogno delle autorizzazioni di scrittura per caricare i file - ma se lo desideri, puoi rimuoverli in seguito - probabilmente, se qualcuno sta scrivendo in una directory su cui solo il proprietario può scrivere - il tuo account è stato compromesso - che è uno dei motivi per mantenere autorizzazioni restrittive).

È normale disporre del set minimo di autorizzazioni per eseguire il lavoro. Se il tuo server web e gli utenti condividono un gruppo comune, puoi rimuovere la necessità di dare qualsiasi accesso a o. Le autorizzazioni sono anche correlate agli utenti. Sembra che tu abbia frainteso i permessi ottali.

1. 555 r-xr-xr-xnon lo è rw-rw-rw. Poiché si tratta di una directory, per creare / eliminare i file è necessario aver ximpostato 750 in modo rwxr-x---che sia un buon punto di partenza. Ciò consente all'utente che possiede la directory di aggiungere / rimuovere i file e tutti gli utenti del gruppo comune di accedervi.
2. Lo stesso di 1. sopra.
3. Se si tratta di file veramente statici di 050, si darebbe comunque l'accesso al web server per creare i file in primo luogo 750 sarebbe un minimo.
4. Come sopra 3.
5. 070 sarebbe il minimo per consentire al server web di leggere e modificare i file, ma i file devono essere creati in modo che 770 sia probabilmente più realistico.

In generale si userebbe la modalità 0755, 0775 o 2775 su directory (il bit SGID su directory, per BSD e per Linux se il filesystem è montato con semantica BSD farà corrispondere l'associazione di gruppo di nuovi file alle impostazioni della directory padre piuttosto che GID predefinito del creatore del file). Ciò consente a tutti gli utenti di attraversare (chdir in e attraverso) e leggere (eseguire il comando ls o eseguire le chiamate di sistema readdir / read) le directory in questione. Le alternative aggiungono opzioni di gruppo / scrittura e, come notato, il bit SGID, nelle directory, può aiutare a mantenere tutti i file e le sottodirectory associati a un gruppo adatto.

Per i file si userebbe normalmente 0644 o possibilmente 0664 (leggibile dal mondo e scrivibile in entrambi i gruppi o meno). Ovviamente per gli script e i binari CGI è necessario aggiungere x-bit; e per alcune situazioni speciali, con binari estremamente ben testati, si potrebbero aggiungere bit SUID o SGID. Normalmente UNIX e Linux ignoreranno il bit SUID / SGID sugli script e onoreranno la sua semantica solo per i binari compilati ed eseguibili nativi. Tuttavia, potresti eseguire il tuo sito sotto qualcosa come Apache con un modulo come "setuidhack" che può essere usato per rendere il web server onorare i bit SUID / SGID anche su script interpretati. (Questo viene fatto dal demone HTTP stat () ing ogni file e usando il proprio codice fork () / execve () personalizzato, interpolando la stringa dell'interprete corretta nel vettore execve () piuttosto che passare semplicemente l'eseguibile '

Queste sono solo le linee guida più generali. Non sono "perfetti" per tutte le situazioni e dovresti assolutamente consultare i documenti per il tuo server web e qualsiasi applicazione web o framework che stai installando e configurando ... e probabilmente vorrai consultare un esperto di sicurezza UNIX prima di te esporre qualsiasi file, codice o server a Internet pubblico.