Newsgroup: it.comp.os.linux.sys
Titolo: AllowOverride

Che voi sappiate nel 2012 c'è qualche rischio di sicurezza nel mettere
 
AllowOverride all
 
nelle direttive di un virtualhost?
-- 
g4b0, linux user n. 369000
http://brosulo.net
 

 nelle direttive di un virtualhost?
 
Dipende da chi può scrivere nella docroot e come ;-)
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 
 
 

 Dipende da chi può scrivere nella docroot e come ;-)
 
È  una macchina di hosting, quindi potenzialmente chiunque. Nel caso
specifico dei caproni :D
 
Seriamente parlando, devo permettere a dei clienti di usare un .htdocs
per aumentare a piacimento la dimensione dei file di upload (hanno
comunque una quota disco impostata) e per mettere sotto http basic auth
alcune dir.



Allora consentigli quello che gli serve e non altro.
 
Non credo tu voglia autorizzarli a consentire ad apache di seguire un
symlink verso /etc/passwd dalla loro docroot, per dire ;-)



Se è un hosting si spera che siano chrootati nella loro home, quindi 
symlink a /etc li escluderei, sbaglio?
M
 
-- 
I fatti mi cosano
 
 

 symlink a /etc li escluderei, sbaglio?
 
 
Dipende: questo ce lo deve dire l'OP. O:-)
 
Ma oggi come oggi di hosting in chroot non ne vedo molti in giro: la
maggior parte dei CMS in circolazione, per girare correttamente, si
porta dietro talmente tanta roba che in chroot finisci per metterci
praticamente tutto il sistema operativo...
 
Il che, in un ambiente in cui il SW da far girare lo decide l'utente
finale (quindi puoi ritrovarti dentro qualsiasi idiozia), rende
l'approccio difficilmente sostenibile:
 
alla fine, ad approntare l'ambiente in chroot ci perdi in assistenza
(per far girare correttamente la follia che l'utente di oggi ha deciso
di usare) più di quanto ci guadagni in sicurezza (sul piano strettamente
economico, almeno).
 
In ambiente multiutente una adeguata separazione dei privilegi e unita
ad una sapiente gestione dei permessi è di solito sufficiente; magari
uniti a meccanismi di MAC
 
Ma chroot in quanto tale è abbastanza difficile...


 Ma chroot in quanto tale è abbastanza difficile...
 
Anche perchè il chroot si porta dietro tanta sicurezza quanta tanta 
scalabilità si ciuccia.
 
Su apache/php/CGI, avere ogni esecuzione in chroot implica che (quasi) ad 
ogni richiesta devi fare un fork() che succhia via parecchie risorse.
 
Su un hosting di basso costo (perchè altrove non ha senso) lo scopo è 
massimizzare il numero di virtual host per server e il chroot, 
semplicemente, non scala.

 uniti a meccanismi di MAC
 
Infatti la macchina é configurata in questo modo:
 
suPHP per far girare ciascun vhost con il proprio utente, e ciascun
utente ha accesso solo alla propria home. In questo modo il directory
traversal é inibito.
 
Effettivamente con il followSymlink riesco a visualizzare /etc/passwd,
probabilmente é meglio disabilitarlo :)


 uniti a meccanismi di MAC
 
Hai qualche link? Questi mi sfuggono...


 Hai qualche link? Questi mi sfuggono...
 
Apparmor, SELinux...


 
 
Ah, ok! MAC é l'acronimo di?


 Ah, ok! MAC é l'acronimo di?
 
Mandatory Access Control
