Newsgroup: it.comp.sicurezza.unix
Titolo: Apache security

Ciao!
Avendo l'esigenza di mettere in piedi un server apache per più domini
virtuali mi sto imbattendo nel problema dei permessi. Premetto che non sono
esperto in materia. Adesso gestisco così la cosa: per ogni sito c'è un
utente che accede via ftp, appartiene al gruppo apache e pubblica in ~/hml
(se non appartenesse al gruppo apache il server web non avrebbe i permessi
per leggere i suoi files). Ora mi sorge un dubbio: apache gira con utente
apache, di conseguenza mi chiedo se chiunque abbia la possibilità di
pubblicare un sito possa quantomeno leggere tutti i files presenti sul
server apparteneti al gruppo apache, quindi i files di tutti gli utenti.
Incuriosito dalla cosa ho fatto uno script in php che copiava un file
presente nella home di pippo in quella di pluto, e la cosa ha funzionato!!!
Leggendo qua e la ho trovato una impostazione da mettere in php.ini
"safe_mode On" che mi ha risolto il problema, ma mi chiedo se esistono
ancora problemi di questo genere, tenendo in considerazione il fatto che
nessun utente può mettere script nella /cgi-bin in quando ad un livello
superiore. C'è un modo migliore per gestire i permessi degli utenti?Altra
cosa: dal punto di vista della sicurezza quali moduli è meglio non
installare in apache? Ad esempio ho letto che mod_perl permette a chiunque
di leggere i files presenti sul disco (un po' come avviene con php). Grazie
in anticipo a chiunque mi fornirà qualche dritta

 "safe_mode On" che mi ha risolto il problema, ma mi chiedo se esistono
Si, hai risolto il problema per PhP, non per altre cose. chiunque possa
utilizzare apache (e quindi tutti coloro che hanno accesso alla porta
80) possono leggere e scrivere in ~/html, perche' e' il processo di
apache a poterlo fare, e di fatto, lo fa!
La mia soluzione e':
1) se l'utente deve poter scrivere solo sulla propria directory (come mi
pare, dato che stiamo parlando di ~/html) allora cambia i permessi in
750, in modo che gli utenti del gruppo apache non possano scrivere in
tale directory, ma l'owner si.
2) se ~/html e' una directory che deve essere accessibile al gruppo
apache anche in scrittura, cambia i permessi in 775 e fai girare apache
come utente, che ne so, www, cosicche' non abbia permessi in scrittura, 
ma solo in lettura. Chiaramente cio' permette a tutti gli utenti locali
di leggere i files nelle altre directory, ma del resto lo possono anche
fare via www.
Sicuramente la soluzione migliore e' la prima, IMHO.
HappyCactus
-- 
Keyboard not present or keyboard error
Press F1 to resume

 virtuali mi sto imbattendo nel problema dei permessi. [...]
Esistono varie soluzioni nella configurazione di Apache e dei permessi
delle directory che permettono il lavoro in multiutenza senza interferenze
tra i vari utenti, in modo che ciascuno possa gestire il proprio spazio,
i propri files e i propri CGI.
Le ricette prevedono di attivare il supporto SUEXEC di Apache (che ti
permette di eseguire i CGI degli utenti ciascuno con la sua identita')
e poi di eliminare gli interpreti incorporati (mod_perl, mod_php,
ecc.) perche' sono eseguiti sempre con la stessa identita'. Maggiori
dettagli nella mia home page.
Visto che dici che nessun utente puo' inserire nuovi CGI, il tutto si puo'
semplificare: elimina solo gli interpreti incorporati.
Ciao,
// Umberto Salsi
//
// 
http://digilander.iol.it/salsi
 <-- GnuPG key available here!
// Key fingerprint = B957 FB00 10F5 A770 4A26  2D80 BE2C F6CD 77E9 29AE

Innanzitutto grazie per le vostre risposte che mi hanno aperto gli occhi :)
Attualmente la mia situazione è la numero 1) descritta da HappyCactus, ad
esempio la home del mio utente è:
drwxr-x---   11 topper   apache       4096 Nov 26 17:20 topper
così quella degli altri utenti. Per quanto riguarda php ho adottato la
soluzione del mio post originale, ovvero ho abilitato la voce "safe_mode On"
in /etc/php.ini e spero di avere risolto ogni tipo di problema con php
(bachi esclusi naturalmente...). Attualmante non permetto a nessun utente di
mettere script nella propria cgi-bin se non previa autorizzazione, quindi
altro possibile problema risolto. Per ora ho commentato nel file di
configurazione tutto quello che riguarda mod_perl, ma mi chiedevo se non
esiste un modo di poterlo utilizzare facendo magari delle modifiche come per
mod_php.
Un'ultima cosa: con i permessi così settati in teoria è ancora possile per
un utente via web accedere in sola lettura alla ~/html di ogni utente (non
con php, ho provato), in quale altro modo qualcuno potrebbe fare ciò? Perchè
è vero che comunque tutti i file sono accessibili via web, ma è anche vero
che se ho un file php che ad esempio si connette ad un database (e contiene
username e password per farlo) e lo vedo tramite browser questo elaborerà la
pagina e non visualizzerà il codice della stessa, ma se qualcuno tramite una
pagina pubblicata sul proprio spazio visualizzasse un file presente nella
home di un'altro potrebbe vederne i dati. Sbaglio qualcosa o il discorso
fila?
Ho letto che apache 2.0 permetterà di far girare ogni virtual con un gid
diverso, tutti sti problemi dovrebbero venire risolti...
P.S. La home page di Umberto Salsi è ora nei miei bookmark :)

 fila?
Qui non capisco. Hai detto che nella home degli altri non ci puo' essere
contenuto CGI. In ogni caso, se uno visualizza la pagina direttamente,
puo' vederne il sorgente html, dal browser. Quindi il problema non si
pone.
O sbaglio?
In ogni caso tieni conto che hai sempre la possibilita' di utilizzare in
ogni directory i files .htaccess e proteggere le pagine con password (e'
quello che o fatto per permettere agli utenti di gestire il server,
quali le code di stampa, etc...)


 O sbaglio?
Si si, mi sono spiegato male. Mi chiedevo se oltre a php e cgi esiste
qualche altro modo che permetta ad un utente di leggere i file degli altri.
Via browser credo proprio che non sia possibile.

 Via browser credo proprio che non sia possibile.
Infatti, a meno di buchi di apache (ma non ne risultano, attualmente).
Invece con IIS si puo'! :)
Quindi e' indispensabile usare CGI (PhP, perl, script bash, eccetera.)
Soprattutto le applicazioni devono prevenire certi bachi che possano
compromettere la sicurezza del sistema (classico quello di non usare i
doppi apici negli script...)
