[gull] Php safe mode, c'est valable, selon vous?

[Marc SCHAEFER]

On Mon, Jul 04, 2005 at 03:42:09PM +0200, fischer at ludwin.net wrote:
> > `safe_mode' évite que des scripts PHP écrits par un client X puissent
> > aller lire les fichiers d'un client Y, les effacer, lancer des commandes
> > sur la machine, etc.
> 
> M'enfin, les utisateurs ne sont pas tous root, tout de meme...

Le problème est que tous les utilisateurs de mod_php exécuteront leurs
scripts sous le même UID UNIX.  Cet UID ne peut pas modifier des
fichiers systèmes (/etc/, etc) mais il peut lire tous les fichiers des
clients.

Prenons un exemple précis. Le client 1 a une base de données PostgreSQL
privée, qui est accédée par les scripts de gestion de la base, accès
protégés par une authentification WWW quelconque.

Cas 1:
   scripts suEXEC en CGI
      dans ce cas, la performance est moindre, mais comme le script
      tourne sous l'UID du client concerné, si le client a bien mis
      les permissions à ses scripts, personne ne peut voir les mots
      de passe dans les scripts d'accès à la base de données.
      (ou encore accès IDENT ou équivalent via socket, dans ce cas
       les mots de passe ne figurent même pas dans les scripts).
      SECURITE OPTIMALE

Cas 2:
   scripts mod_perl ou mod_php
      tous les scripts tournent sous l'UID du serveur Apache (p.ex. www-data)
      dans ce cas, le client Y peut aller lire les fichiers du client X
      et donc obtenir le mot de passe d'accès à sa base de données.
      SECURITE DESASTREUSE EN MULTI-UTILISATION

pour diminuer l'impact du cas 2 sur la sécurité, PHP a développé
safe_mode, qui correspond à peu près à réintroduire la sécurité UNIX là
où il ne peut y en avoir car l'UID est le même.  En bref, ce n'est pas
la notion d'UID qui est employée pour la sécurité, mais la notion
d'arborescence. Un client X ne peut accéder qu'aux fichiers et
sous-répertoires situés sous son arborescence de serveur WWW virtuel,
et, éventuellement en lecture seulement, des répertoires partagés comme
des répertoires de fichiers d'inclusion.

Il ne peut pas non plus lancer des commandes UNIX, car celles-ci ne
seraient pas soumises à la sécurité safe_mode.

PHP documente assez bien ce que fait safe_mode, une simple recherche
devrait vous permettre de déterminer ce qui est affecté par cette
option et d'éventuellement corriger les bugs de vos (?) scripts.

> > PS: en théorie PHP8 avec Apache2 tourne chaque instance de
> > l'interpréteur dans un contexte différent (PHP server)
> 
> Php 8? Deja?

C'était un gag. Avec PHP la plupart des demandes de support finissent
non pas en un simple patch de 3 lignes, mais `mettez à jour à la version
suivante' -- qui expose d'autres bugs.

Redevenons sérieux.

Sauf erreur le mod_php d'Apache 2 ne fonctionne pas encore suffisamment
bien pour être exploité. C'est Perl qui a ce concept d'interprète dans
des processus dans Apache 2, pas PHP (à ma connaissance). Le concept
d'interprète combine la sécurité du suEXEC CGI avec la vitesse du
mod_perl.

PS: le mieux pour vous, est, finalement, de déterminer avec votre hébergeur
ce qu'il faut faire pour que vos scripts fonctionnent dans de bonnes
conditions. Même s'il existe peut-être encore aujourd'hui des hébergeurs
de masse sans safe_mode, ils vont tous disparaître. Par contre, il
existe des solutions alternatives, comme tourner votre serveur WWW dans
une machine virtuelle (UML ou VLS) avec son propre processus Apache sous
votre contrôle entier (vous serez root dans votre machine virtuelle).
La plupart des hébergeurs pas trop bons marchés ont un service de
support compétent et pourront vous aider.

Bien sûr, il faut éviter de supposer qu'un hébergeur à 5.- par mois
offre des solutions personnalisées, des sauvegardes réellement faites
ou du support de qualité.