[php - sicurezza] proteggere accesso al filesystem

[nik600]

scusate

ma tramite le varie funzioni di accesso al file system (dir(),mkdir(),rmdir(),read()....)

nulla vieta a chi può eseguire una pagina php sul server di andare e scopiazzarsi in giro sul filesystem del server tutte le info che gli interessano!

Voi direte, no solo dove l'utente con cui gira apache può leggere, scrivere, eseguire

Ok, è vero, ma supponiamo che vi siano 2 virtual host, entrambi avranno sicuramente almeno il permesso di lettura per l'utente daemon, nobody, o quello con cui gira apache!

E quindi nulla vieta ad un virtualhost di leggere le password di connessione al db (ad esempio..) presenti in un altro virtual host!

Come si può ovviare a questo problema?

[mark2x]

Originariamente inviato da nik600
tramite le varie funzioni di accesso al file system (dir(),mkdir(),rmdir(),read()....) nulla vieta a chi può eseguire una pagina php sul server di andare e scopiazzarsi in giro sul filesystem del server tutte le info che gli interessano!

Voi direte, no solo dove l'utente con cui gira apache può leggere, scrivere, eseguire

Esatto, ed è per questo che l'utente con cui gira Apache deve avere permessi davvero minimi (e linux sa cosa proteggere, in tutto il filesystem... rendendolo di default "invisibile" a tale utente). E fin qui ci siamo.

Ok, è vero, ma supponiamo che vi siano 2 virtual host, entrambi avranno sicuramente almeno il permesso di lettura per l'utente daemon, nobody, o quello con cui gira apache!

E quindi nulla vieta ad un virtualhost di leggere le password di connessione al db (ad esempio..) presenti in un altro virtual host!

Come si può ovviare a questo problema?

Non sono un fan di queste cose [ho sempre e solo usato server dedicati], ma la direttiva open_basedir credo possa essere associata a distinti VHost. E questa farebbe al caso tuo (in teoria).

In ogni modo, per la domanda sui file di password di connessione al db, beh, il mio consiglio è quello di "zendare" tutti i file php, compresi i file di pwd (OVVIAMENTE le pwd le inserisci in file php vero? ).

[nik600]

In ogni modo, per la domanda sui file di password di connessione al db, beh, il mio consiglio è quello di "zendare" tutti i file php, compresi i file di pwd (OVVIAMENTE le pwd le inserisci in file php vero? ).

beh, io ho un server mio su cui faccio girare tutte le mie applicazioni, il fatto è che ho anche alcuni clienti hostati sul mio server, e da qui questa esigenza.

lavorerò su open_basedir

domanda però:

- se io da vhost specifico open_basedir =1

l'utente può da con php reimpostarsi il valore con php_ini(...) ?

[mark2x]

Originariamente inviato da nik600
Se io da vhost specifico open_basedir =1 l'utente può da con php reimpostarsi il valore con php_ini(...) ?

No, è PHP_INI_SYSTEM: entry can be set in php.ini or httpd.conf.

http://it2.php.net/manual/en/ini.php#ini.list

[mark2x]

Non avendo mai utilizzato di persona quanto ti ho suggerito ed interessando anche a me: funziona? Come hai proceduto?

:master:

[daniele_dll]

open_basedir indica le path a cui php può accedere, ed ovviamente può essere usato anche nel virtual host come anche nel file di configurazione principale, non è un valore booleano o numerico

usandolo limiti l'accesso

inoltre, usando anche il safe_mode è possibile limitare ulteriormente l'accesso ai file perché non solo php potrà accedere SOLO ai file ai quali apache può accedere ma in aggiunta a questo potrà accedere solo ai file di cui apache è proprietario!

per intenderci ... /bin/sh è accessibile in lettura e esecuzione da qualsiasi programma ma scrivibile solo da root di conseguenza senza safe-mode php può eseguire sh, mentre col safe-mode php, dato che sh non è settato sull'utente di apache, non può accedervi

Inoltre, sempre con il safe-mode, è possibile limitare i programmi ai quali è possibile accedere

dal punto di vista di sicurezza, se è ben configurato, si può stare tranquilli

[mark2x]

Originariamente inviato da daniele_dll
open_basedir indica le path a cui php può accedere, ed ovviamente può essere usato anche nel virtual host come anche nel file di configurazione principale, non è un valore booleano o numerico

Ecco, esattamente un esempio pratico di questo volevo vedere (un giorno mi servisse...)

inoltre, usando anche il safe_mode è possibile limitare ulteriormente l'accesso ai file perché non solo php potrà accedere SOLO ai file ai quali apache può accedere ma in aggiunta a questo potrà accedere solo ai file di cui apache è proprietario!

Tu lo usi?
Ho sentito da più fonti che tale limitazione è superabile dagli script PHP in vari modi. Io per parte mia non l'ho mai usato quindi non so dire: in caso mi serva sicurezza (ho sempre server dedicati e "potenti") vado dritto di virtualizzazione dei servizi su virtual machines (!!) più volendo (piiiiccole) gabbie chroot.

per intenderci ... /bin/sh è accessibile in lettura e esecuzione da qualsiasi programma ma scrivibile solo da root di conseguenza senza safe-mode php può eseguire sh, mentre col safe-mode php, dato che sh non è settato sull'utente di apache, non può accedervi

Inoltre, sempre con il safe-mode, è possibile limitare i programmi ai quali è possibile accedere

dal punto di vista di sicurezza, se è ben configurato, si può stare tranquilli

Sì, però concorderai che uno della shell non se ne fa un fico secco se non ha i permessi di andare a "curiosare" da alcuna parte (come ad esempio l'utente mysql di MySQL)....

[daniele_dll]

Originariamente inviato da mark2x
Tu lo usi?
Ho sentito da più fonti che tale limitazione è superabile dagli script PHP in vari modi. Io per parte mia non l'ho mai usato quindi non so dire: in caso mi serva sicurezza (ho sempre server dedicati e "potenti") vado dritto di virtualizzazione dei servizi su virtual machines (!!) più volendo (piiiiccole) gabbie chroot.

di solito se posso io lo uso

Sì, però concorderai che uno della shell non se ne fa un fico secco se non ha i permessi di andare a "curiosare" da alcuna parte (come ad esempio l'utente mysql di MySQL)....

beh .... dipende ... ad esempio puoi leggere il file passwd e quindi sapere quali utenti ci sono nel sistema e tentare un bruteforcing dall'interno sfruttando il comando login, oppure puoi provare a lanciare del codice malevole ^^

[mark2x]

Originariamente inviato da daniele_dll
beh .... dipende ... ad esempio puoi leggere il file passwd e quindi sapere quali utenti ci sono nel sistema e tentare un bruteforcing dall'interno sfruttando il comando login, oppure puoi provare a lanciare del codice malevole ^^

E qui mettiamo una bella ombra sulle password... (shadow pwd)

EDIT. Aggiungo che su Debian di default le pwd non stanno nel file suddetto.

[mark2x]

Cmq torno alla mia domandina: qualcuno mi posta se lo ha un esempio di configurazione di open_basedir diversificata per più vhosts?

10x.