Ma infatti il problema e’ mod_ruby (e anche mod_python) e cosi’ molti
altri.
Mod_php (e mod_perl) hanno una base talmente ampia di utilizzo che la
preoccupazione e’ minima (ti dico solo che il modulo per apache di unbit
che prende i dati degli account da db lo abbiamo fatto in mod_perl,
nonostante le mie fissazioni).
Pero’ come dici l’approccio sistemistico e’ diverso, e mi viene l’ansia
quando so che molti provider utilizzano mod_php in ambienti
condivisi…tutti gli script di utenti diversi che girano con lo stesso
permesso…brrrr
La, il problema e, in parte, il linguaggio stesso. Con un
linguaggio piu serio come Tcl (o Ruby, naturalmente), puoi fare un sandbox dove tieni gli utenti in una zona molto piu ristretta. Con
Rivet, per esempio, ho implementato un sistema che da` ad ogni virtual
host un interprete suo (che poi uno potrebbe customizzare per
funzionare come vuole).
–
David N. Welton
Linux, Open Source Consulting
On 3/14/07, David W. [email protected] wrote:
permesso…brrrr
La, il problema e, in parte, il linguaggio stesso. Con un
linguaggio piu serio come Tcl (o Ruby, naturalmente), puoi fare un sandbox dove tieni gli utenti in una zona molto piu ristretta. Con
Rivet, per esempio, ho implementato un sistema che da` ad ogni virtual
host un interprete suo (che poi uno potrebbe customizzare per
funzionare come vuole).
Il problema, correggetemi se sbaglio, è che i processi di Apache girano
tutti con l’utente di Apache. Quindi qualsiasi approccio mod_* in un
ambiente condiviso finisce per fare girare tutte le web app con lo
stesso
utente.
M
Il giorno mer, 14/03/2007 alle 23.49 +0100, David W. ha scritto:
La, il problema e, in parte, il linguaggio stesso. Con un
linguaggio piuserio come Tcl (o Ruby, naturalmente), puoi fare un sandbox dove tieni gli utenti in una zona molto piu ristretta. Con
Rivet, per esempio, ho implementato un sistema che da` ad ogni virtual
host un interprete suo (che poi uno potrebbe customizzare per
funzionare come vuole).
Ma nuovamente non e’ un approccio sistemistico 
La sicurezza deve essere al layer piu’ basso possibile (addirittura nel
kernel, con MAC o varie tabelle di namespace delle risorse).
Una sandbox sicura non deve preoccuparsi solo dei permessi ma anche
delle risorse come cpu,ram,stack il locking dei file e blah blah.
Questo ‘ambiente relativamente sicuro’ andrebbe costruito a uno strato
inferiore al linguaggio.
Addirittura la vecchia tecnica usata da molti fornitori di hosting del
chroot per ogni utente in cui far girare tutto e’ una soluzione solo ad
alcuni dei problemi di sicurezza. (senza contare che ‘fuggire’ da un
chroot e’ abbastanza facile a meno che di utilizzare patch a livello
kernel ad-hoc)
Siamo in un loop, possiamo continuare a parlarne per mesi, e il
programmatore avrebbe sempre ragione cosi’ come il sistemista
In compenso ho iniziato a giocare con Rivet
Il giorno gio, 15/03/2007 alle 08.56 +0100, Matteo V. ha scritto:
condivisi…tutti gli script di utenti diversi che girano con lo stesso
Il problema, correggetemi se sbaglio, è che i processi di Apache girano
tutti con l’utente di Apache. Quindi qualsiasi approccio mod_* in un
ambiente condiviso finisce per fare girare tutte le web app con lo stesso
utente.
Amen 
Anche se il modulo itk di apache 2.2 dovrebbe cambiare un po’ le carte
in tavola
–
Roberto De Ioris
http://unbit.it
JID: [email protected]
Wii: 2999 4476 3509 0964