Newsgroup: it.comp.os.linux.sys
Titolo: Apache mod_chroot & suphp

Qualcuno sta usando con successo mod_chroot accoppiato
a suexec?
Ne sto uscendo matto, milioni di librerie da portarsi dietro...
Qualche metodo piï¿œ semplice?
suexec non ï¿œ una via percorribile perchï¿œ richiede il +x sui
file php ed il filesystem con le pagine in php ï¿œ in noexec.

 Qualche metodo più semplice?
Hai pensato a apache2-mod-itk ?
Bye.

 Hai pensato a apache2-mod-itk ?
No, ma dubito non cambi nulla dall'eseguire php tramite suphp.
C'è solo e soltanto PHP, nessun altro linguaggio di scripting
per cui dovrebbe bastare suphp

Peregrino 'Pipino' Tuc ha scritto:

Ok, in parole povere che devi fare esattamente?

 Ok, in parole povere che devi fare esattamente?
Pararmi il culo.
Che in parole meno povere significa:
consentire agli utenti che caricano le cagate in php
di eseguire determinati eseguibili, e solo tali eseguibili.
Senza safemode di php, le funzioni exec vanno in giro per il
sistema e non ï¿œ bello.
In teoria (non ho mai provato) mettendo suphp in chroot, le
funzioni exec di php non potranno mai uscire dal chroot, per cui
gireranno in una mia gabbia con dentro solo i 3 programmi di cui
necessito.

Peregrino 'Pipino' Tuc ha scritto:

Apposta hanno inventato SELinux...
Ed in ogni caso l'utente puï¿œ sempre caricare l'applicazione nel proprio 
spazio web e richiamarla con system().
Nota che semplicemente abilitando SELinux rendi de facto impossibile 
l'udtilizzo di applicazioni "critiche" poi se uno vuole richiamare 
/bash/cp piuttosto che scriversi 20 righe di php poco importa no?
Per quel che riguarda i socket invece puoi utilizzare iptables per 
impedire all'utente di aprire connessioni verso l'esterno anche se 
francamente mi sembrerebbe poco pratico, visto che dopo 30 secondi 
qualcuno ti richiamerebbe per chiedere spiegazioni sul perchï¿œ non 
funziona piï¿œ CURL o simili..
In pratica non puoi avere la moglie ubriaca e la botte piena, o castri 
gli utenti o li lasci liberi di lavorare, ma chi vorrebbe un hosting per 
html statico oggi?

 html statico oggi?
Chi ha parlato di statico?
Il problema, sostanzialmente, vien fuori da imagemagick.
L'unico applicativo che devono poter eseguire sul server ï¿œ imagemagick.
Tutto il resto niente.
Un chroot farebbe comodo perchï¿œ gli utenti non potrebbero uscire da li
e dentro il chroot io potrei mettere solo imagemagick.
Ma penso di risolvere in maniera piï¿œ elegante:
blocco tutte le funzioni di esecuzione, system, exec, passthrough e cosï¿œ 
via.
Bloccandole, suphp + open_basedir mi risolverebbero ogni problema.

 e così via fino alla fine.
Tipo
$ apt-cache search makejail
makejail - Automatically create chroot jails for programs
?
Enrico

 Hai pensato a apache2-mod-itk ?
Questo è una figata veramente.
Non lo conoscevo, ma è un sacco meglio di
suphp.
Fa girare l'intero apache con determinati utenti
il che mi permette di fare cose tipo:
chown utente:utente -R /var/www/utente
chmod 700 /var/www/utente -R
cosa non possibile con suphp in quanto apache (che
girerebbe con i permessi di www-data) non riuscirebbe
ad accedere alle directory.
Suphp cambia utente solo a php, itk invece lo cambia a tutto
apache, compreso i php.
figata!
Chi lo usa in produzione?
Da quel che leggo è anche leggermente più veloce di suphp e
mi permette di usare mod_php con i vari parametri in htaccess

 makejail - Automatically create chroot jails for programs
interessante, ma credo di aver risolto con apache itk

 Bloccandole, suphp + open_basedir mi risolverebbero ogni problema.
openbasedir � una cagata di cui nonfidarsi, mai.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 apache2-mod-itk
leggendo cosa fa, rimango dell'idea che, come discusso in passato, fastcgi
(o fgci) + suexec sia la scelta migliore.
Max


 (o fgci) + suexec sia la scelta migliore.
son due cose differenti.
itk ti fa girare l'intero vhost con i permessi dell'utente X.
suexec fa girare solo php

 openbasedir � una cagata di cui nonfidarsi, mai.
da noi si direbbe:
piuttost che gnint l'� mej piuttost (non so come si scrive)
che tradotto significa:
piuttosto che niente � meglio piuttosto.
Non mi fido di open_basedir, ma lo uso ugualmente, da quella
mezza protezione in pi�. Non tutti sono esperti hacker in grado
di bypassarlo, molti sono solo bambinetti lamer che non riuscirebbero
a fuggire dalle restrizioni.
Tant'� che sto cercando ANCHE altre soluzioni.
Piuttosto che suexec preferieri suphp.
Tu cosa consigli?

 suexec fa girare solo php
Inoltre, con suexec/suphp non puoi impostare a 700 i permessi
delle directory e a 600 i permessi dei file.
Apache deve sempre accedere a tutto l'albero delle directory
e quantomeno leggere i file html non elaborati da suphp
AFAIK, un file html non processato da suphp deve avere almeno 644
poich� � apache che legge (www-data) e non suphp con i permessi
dell'utente.
Se www-data legge un file di propriet� X, significa che quel file
� leggibile da tutti, per cui bucando l'openbasedir di PHP l'utente
Y pu� leggere i file di X allo stesso modo in cui apache legge i file.
Considerato il livello degli utenti, *sicuramente* si salvano in 644
anche il file di configurazione degli applicativi php con dentro le
password, ti bucano l'openbasedir, ti leggono la password del db e
ti fan fuori il sito del cliente.
Forse si potrebbe risolvere questa problematica facendo processare anche
i file html a suphp, ma sarebbe solo uno spreco di risorse, o no?
Con ITK tutto questo casino non accadrebbe, apache stesso gira con i
permessi dell'utente, per cui puoi benissimo salvare in 700 le directory
e in 600 i file, se bucano l'openbasedir dell'utente X non potranno mai
accedere ai file dell'utente Y perch� non sono word-readable.
Scrippettino in cron che ogni ora forza 700 alle directory e 600 ai file
e dovresti aver risolto.
Non so se pu� aver senso piazzare *anche* suphp.
Inconveniente di itk: apache gira (compreso tutti i child) come root.
Eventuali exploit su apache potrebbero essere pericolosi, ma oggigiorno
credo (imho) che gli exploit diretti ad apache siano di qualche ordine
di grandezza inferiori a quelli di php. Credo forse valga la pena di
correre il rischio.

 correre il rischio.
No.
PHP Ha poche vulnerabilità. Come Apache.
Sono gli script di PHP che sono scritti di solito in malo modo.
Per la cronaca l'ultima in ordine cronologico era di apache (mod_proxy) non 
di php.
Max

 Sono gli script di PHP che sono scritti di solito in malo modo.
Stiamo parlando della stessa cosa, ho scritto male.
Per vulnerabilità di PHP intendo vulnerabilità degli SCRIPT in PHP
non del PHP stesso.
Per cui, potrebbe giocare maggiormente a mio vantaggio.
Anche se apache gira come root, itk mi permetterebbe di
restare ulteriormente al sicuro rispetto ad un semplice
suphp perchè protegge TUTTI i file, non solo quelli PHP.
Considerato che apache e php sono prodotti abbastanza sicuri,
credo valga la pena correre il rischio e far girare i child
come root, alla fin fine, eventuali exploit dovrebbero essere
diretti ad apache PRIMA della lettura del virtualhost, perchè
una volta letto, itk cambia i permessi.