Newsgroup: it.comp.www.php
Titolo: [PHP5] Sicurezza, schifezze, Safe_mode ed è già l'ultima beta

In altri post, è venuto fuori il problema della sicurezza e di come classi e
script debbano 'pagare lo scotto' di un cambio di parametrizzazione del
php.ini creando confusione.
Con l'avvento di php 4.1.x società di hosting e sviluppatori hanno visto,
per rispettare problematiche di sicurezza non previste, mettere KO
tantissimi clienti che avevano software installati (i classici forum,
progetti, phpAds, etc etc quelli 'soliti' di cui si posta sempre anche qui
insomma).
Seppur, come sviluppatore, sia io dell'idea che il codice debba essere
scritto per poter funzionare anche con questi cambi di configurazione (e
comunque SEMPRE il software fatto deve andare con la configurazione di
default del Php), vero è che non è facile far capire questa cosa ai clienti
di hosting che, semplicemente, dicono "o mi mette safe_mode off oppure
cambio provider" oppure "prima funzionava ora non funziona piu' " causando
problematiche, tra cui:
1) Lamentele / brutte figure (nononstante i numerosi avvisi).
2) Script da aggiornare / ritoccare
3) Tempo perso a spiegare
4) Aggiornamenti fatti da programmatori interni perchè chi ha sviluppato un
software non rilascia una versione 'per safe_mode' ma si limita a scrivere
'richiede safe mode off' e senza il modo di farsi pagare il tempo dei
programmatori che hanno messo a posto le cose.
Vero è che chi usa Php deve tenersi aggiornato coi changelog... ma chi ha
un'esperienza seria e reale di server dedicati, hosting, etc etc sa che è
una falsa scusa perchè i clienti scaricano, copiano, configurano i loro 2-3
files config.ini e via andare... e vogliono che le cose funzionino.
E' vero che in questo caso il cliente non ha ragione... ma ha davvero tutti
i torti a lamentarsi di safe_mode e register_globals ?
Chi ha il coraggio di sostenere che safe mode, register globals etc etc
siano effettive soluzioni di lavoro per garantire la sicurezza ?
A me sembrano delle schifosissime pezze messe lì a tappare le falle... e chi
proprio non può lavorare con safe_mode ON si deve assumere la responsabilità
di eventuali buchi aperti.
In pratica, dal punto di vista Php, dicono: "Arrangiatevi, noi il problema
lo chiudiamo così, moh arrangiatevi".
Molti ISP poi non hanno assolutamente competenza per poter configurare un
server e molti fanno affidamento a sistemisti 'abbozzati' che, pur di
vendere un hosting da 2euro, attivano qualsiasi opzione il cliente richieda.
Purtroppo non c'è neppure una mailing list come i produttori seri hanno che
dia la forza a tutti gli ISP di costringere i clienti a cambiare la loro
impostazione.
Zend dalla sua parte se la tira così tanto con questo Php 5 e sulla piega OO
che sta prendendo, ma ancora non ha risolto (mi pare) il vero problema che
si porta dietro da anni: la sicurezza.
Si perchè altri linguaggi hanno trovato una soluzione, chi in un modo chi in
un altro (SandBox di CF, Security Manager di Jk, etc), e noi (in modo
ridicolo) siamo qui incasinati con funzioni di ftp, utenti di apache etc etc
Mi stupisce poi che nessuno si lamenti DI BRUTTO per questa cosa, neppure
sui forum di Zend, e si accetti a testa bassa (aggiungo: e solo perchè Php è
free) una situazione simile.
Ma voi, cosa ne pensate del fatto che si dovrebbe trovare una soluzione
diversa che non castrare le funzionalità alla sicurezza ?
Ciao
Julien

 soluzione diversa che non castrare le funzionalit` alla sicurezza ?
Fatti un bel corso su un SO *nix, impara come funzionano i processi ed
i privilegi delle utenze e poi ne discutiamo.
-- 
I'am what I'am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/1

 A me sembrano delle schifosissime pezze messe lě a tappare le falle...
Ciao Julien,
dopo la questione dell'altro giorno mi sono documentato un po' su come
facciano mod_perl e mod_python....non fanno e in mod_perl addirittura si
parla di introdurre una cosa del tutto analoga al safe_mode.
Questa mancanza č anche una delle ragioni per cui i fornitori di hosting
stentano a fornire questi due moduli.
suEXEC, come risulta ovvio se si capisce come funziona, č una soluzione
soltanto per i CGI (o FAST CGI).
Poi devo dire che anche se tra i domini che gestisco vi sono un paio di
spazi da 25 Euro all'anno (piů economico di cosě!) non ce n'č uno che abbia
il safe_mode, uno al massimo ricorre a open_basedir e alla limitazione delle
chiamate di sistema.
safe_mode č una soluzione estrema per spazi estremamente economici con
macchine che ospitano centinaia di virtualhost
register_globals
chi stava attento non en aveva bisogno, e chi č pigro puň servirsi di
extract()
Poi chi vuole usare Php bene e a 360% si prende un server virtuale, paga un
po' di piů e fa tutto quello che vuole :)
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Per me la soluzione del server dedicato sarebbe l'ideale, anche da un punto
di vista commerciale eheheh :-D
C'è da dire che sarebbe un delegare al proprietario del server la
responsabilità della sicurezza.
Una cosa che si potrebbe fare (è questo che dicevi) è fare hosting non
utilizzando le proprietà di linux e dei virtual domanis, ma quello di veri e
propri os virtuali indipendenti, associando risorse per ogni cliente...
proprio come si faceva un po' di anni fa...
Julien

Ripensandoci....
forse sono io che mi aspetto una framework completa, e alla fine php è solo
un interprete...un ottimo interprete, ma non altro.
J

 h solo un interprete...un ottimo interprete, ma non altro.
Se per "framework completa" intendi una cosa tipo JSP/Servlet allora
si, PHP e' solo l'interprete.
Non so se questo sia un pregio od un difetto in quanto le curve di
apprendimento di PHP e di JSP/Servlet sono molto diverse (PHP e' piu'
facile, e prima produttivo).
Se non erro qualcuno aveva parlato di un sistema per implementare in
PHP l'interfaccia servlet stile Java (o proprio Java). Non parlo della
Java Servlet SAPI ma di qualche cosa di diverso.



I framework stanno venendo fuori a poco a poco, ma alcuni sono accusati di
scimmiottare troppo Java e non tenere conto, ad esempio, dell'assenza di
persistenza in Php (ogni file, ogni volta, viene "parsato" ed eseguito).
Qui si fa un breve confronto
http://www.jroller.com/page/aspinei/20030821
Quanto all'integrazione servlet di cui parla Setec potrebbe essere questo...
http://phplet.sourceforge.net/modules.php?name=FAQ&myfaq=yes&id_cat=1&categories=About+the+PHPlet+project
La documentazione č ancora scarsissima e qualche commento o spiegazione in
piů da chi lavora con Java sarebbe gradito :)



Beh, se il safe mode ti dà così tanto fastidio cambia server e scegli meglio
il prossimo :)


 e ' corretto che si php a integrarlo
Quoto dal manuale per completezza:
http://it.php.net/manual/en/features.safe-mode.php
[quoto]
The PHP safe mode is an attempt to solve the shared-server security
problem. It is architecturally incorrect to try to solve this problem
at the PHP level, but since the alternatives at the web server and OS
levels aren't very realistic, many people, especially ISP's, use safe
mode for now.
<======================================================================>
La modalita Safe Mode e un tentativo di risolvere il problema di
sicurezza derivante dalla condivisione del server. Dal punto di vista
architetturale non e corretto cercare di risolvere questo problema al
livello del PHP, ma poiche le alternative al livello del web server e
del SO (Sistema Operativo) non sono realistiche, in molti, specialmente
ISP (Internet Service Provider), utilizzano la modalita sicura.
[/quoto]
Il che significa che non si puo' attribuire al PHP la "colpa" (per
cosi' dire) dell'esistenza del safe_mode, bensi' alla scarsita' di
sicurezza a livello di WebServer o SO od alla difficolta' di
implementarla in situazioni di "condivisione del server".


 Julien
-- 
Chinaski FDB
www.glabs.it
email: 
ulloatildisturboglabs.it
togli il disturbo per scrivermi
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Ecco quello che dicevo... la gente scegli chi vende servizi anche in
funzione del fatto che abbia safe_mode attivo o meno...
al posto di scegliere quelli che lo hanno attivo, scelgono quelli che non lo
hanno..
J

 
www.glabs.it


E fanno bene direi :),
di solito safe_mode == accozzaglia di dominii sullo stesso server.
Personalmente non acquisto più spazi che non siano in un server virtuale, il
"problema" del safe_mode non esiste, i prezzi sono abbastanza contenuti e
nel server faccio praticamente tutto quello che voglio.


 cosa aspettarsi.
In che senso "non sa cosa aspettarsi"? 
Il 99% dei provider e' disposto a fornire l'output di phpinfo, per cui
non e' difficile ottenere questa informazione.
Se invece intendi che non e' in grado di valutare le conseguenze
dell'acquisto a basso costo, il problema non e' piu' del provider o del
PHP bensi' dell'utente "ignorante".


 aspettarsi.
se un sito o una applicazione sono sviluppati senza tenere conto delle
basilari procedure di sicurezza evidentemente si tratta di progetti per
cui la questione non è così rilevante.
alcuni dei siti che ho realizzato risiedono tuttora su server con
configurazione allegre, ma visto il tipo di siti la cosa non è considerata
un problema dal cliente finale.
quando parlo di diversificazione del mercato intendo dire che c'è una
fascia di utenza per cui la questione semplicemente non è importante.


 togli il disturbo per scrivermi
J

Speriamo non sia cosě anche per php5 dopo 3 anni dal rilascio ...
4.0.0 - Release Maggio 2000
...
4.3.4 - Release Novembre 2003
Periodo: 3 anni e 6 mesi (42 mesi)
Versioni: 18
Media attuale: 1 nuova versione ogni 2,3 mesi
Ultima disponibile per RH 9 (non fonte mia) 4.2.x
Ultima disponibile per Sun Cobalt 550 4.0.6

 di solito safe_mode == accozzaglia di dominii sullo stesso server.
Se mi spieghi chi non lo fa ?
Penso che ora mai, quasi tutti i provider utilizzino il sistema del
Virtualhosting basato su nome... e funziona se sai come funziona :-)
Tuttavia mi permetto di esprimere una mia opinione personale:
safe_mode si o safe_mode no, molto sta nella competanza e
nella professionalità del sistemista che si occupa della
corretta e sicura configurazione del web server e
conseguentemente dell'utenza, con tutto cio' che ci va dietro. 
Se ti bucano la macchina con uno script, solo perchè hai lasciato troppe
cose al caso... beh, vai a vendere banane; forse quello è un compito
piu' indicato.
Se invece ti bucano la macchina perchè il software era bucato... beh
questo accade anche su un server dedicato.
In passato gli script *.cgi sono stati spesso una pozza di
sangue per mille motivi: il meccanismo suexec IMHO a portato dei
grandissimi vantaggi sotto il profilo della sicurezza e... questo aspetto
si lega al sistema operativo, non al codice. 
Il tutto ovviamente IMHO
Ciao clust

 Virtualhosting basato su nome... e funziona se sai come >funziona :-)
C'è differenza tra avere 10, 100 o 1000 virtualhost: i rischi derivanti
dalla promiscuità con un linguaggio mod_xxx non sono mai del tutto assenti
ma aumentano con l'aumentare delle presenze.
Ecco che il safe_mode è una soluzione estrema per un problema al momento non
risolvibile in server configurati in modo tradizionale.
Alternative:
1 - suEXEC e versione CGI del linguaggio
2 - limitazione open_basedir + disabilitazione chiamate di sistema
3 - più servizi di Apache anzichè uno soltanto (poco realistico)
4 - pochi virtualhost e rischio contenuto
5 - linux user mode e virtual server
Non me ne vengono in mente altre
Ormai quando acquisto uno spazio web lavoro solo con virtual server
(isolamento totale dagli altri spazi , gestione completa quasi come se fossi
root, libertà di frazionamento , a cifre di poco superiori rispetto a quelle
dell'hosting tradizionale)
Mi chiedo se esista qualcosa di simile per Win
