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/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
