A défaut et dans l'urgence (solution absolument pas viable à long terme), il est envisageable de limiter drastiquement l'accès aux fonctions autorisant un fork() et de contraindre PHP à coups de open_basedir.
C'est médiocre point-de-vue isolation, mais le rapport gain/effort n'est pas négligeable dans un premier temps (ça prend quelque chose comme une journée à mettre en place en production, sans franchement de gros risque de se planter). Attention à ne pas oublier : si open_basedir peut être set dans la configuration Apache qui transmet à mod_php, disable_functions est uniquement autorisée dans la configuration native PHP (php.ini et affiliés).
Reste un classique qui tourne de mieux en mieux en production : quite à forker pour séparer les utilisateurs côté Apache, autant se contenter de forker le fautif (PHP) et se tourner vers des technos type fcgi (php-fpm, etc.) qui ont en prime le mérite d'être proprement standardisées et de faciliter grandement la transition de frontend (apache vers nginx est de plus en plus populaire).
J'ai pour ma part en prod un gid par vhost et des utilisateurs rajoutés au cas par cas dans les groupes adéquats.
On Sat, 2012-12-22 at 12:45 +0100, Yann Autissier wrote:
Bonjour,
Le 21/12/2012 18:28, Patrick Proniewski a écrit :
Quelles techniques utilisez-vous avec Apache/PHP quand vous voulez cloisonner des sites web ?
Nous avons développé deux modules PHP :
- un suphp 'light' pour php-fcgi qui set{u,g}id les process php [1]
- une surcharge à la volée des fonctions PHP, qui nous permet de modifier le
comportement des fonctions sensibles (mail, exec, fopen, fsockopen, ...) [2]
[1]. https://github.com/anotherservice/php5-suphp [2]. https://github.com/anotherservice/php5-override
-- Yann Autissier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/