![[APACHE DOCUMENTATION]](images/sub.gif)
La fonctionnalité suEXEC -- introduite à partir de la version 1.2 d'Apache -- donne aux utilisateurs d'Apache la possibilité d'exécuter des programmes CGI et SSI sous des UID distincts de l'utilisateur associé au serveur Web lui-même. Normalement, lorsqu'un programme CGI ou SSI s'exécute, il tourne sous le même utilisateur que le serveur Web.
Correctement utilisée, cette fonctionnalité peut réduire considérablement les risques lorsque l'autorisation est donnée aux utilisateurs de développer et d'exécuter leurs propres programmes CGI ou SSI. Cependant, si suEXEC n'est pas correctement configuré, de nouveaux problèmes peuvent apparaître, voire de nouveaux "trous" dans votre dispositif de sécurité. Si vous n'êtes pas un familier de la gestion des programmes sous setuid root et de leurs implications sur la sécurité, nous vous recommandons fortement d'éviter d'utiliser suEXEC.
Avant de ce jeter tête baissée dans ce document, vous devez prendre connaissance des suppositions faites par le groupe Apache pour la rédaction de ce document.
Premièrement, nous supposons que vous utilisez un système d'exploitation dérivé d'UNIX qui supporte les commandes setuid et setgid. Tous les exemples de commandes sont donnés dans ce contexte. Les autres plates-formes, si elles supportent suEXEC, auront probablement une configuration différente.
Deuxièmement, nous supposons que vous êtes familier de certains concepts de base en matière d'administration et de sécurité système. Ceci sous-entend une bonne compréhension des commandes setuid/setgid et une expérience des effets que ces commandes peuvent avoir sur votre système et sa sécurité.
Troisièmement, nous supposons que vous utilisez une version non modifiée du code suEXEC. L'intégralité du code de suEXEC a été inspecté et testé précautionneusement par les développeurs ainsi que de nombreux beta-testeurs. Toutes les précautions ont été prises pour fournir un base de code simple, "solide" et sûre. Modifier ce code peut créer d'autres problèmes et augmenter les risques quant à la sécurité. Il est fortement recommandé de ne pas modifier le code de suEXEC sauf si vous êtes un spécialiste de la programmation sur ces aspects de sécurité, et souhaitez partager votre expérience avec le groupe Apache.
Dernièrement, le groupe Apache a décidé de NE PAS inclure suEXEC dans la distribution standard d'Apache. A ce titre, la configuration de suEXEC reste une opération manuelle demandant de la part de l'administrateur une attention détaillée. C'est par ce procédé que le groupe Apache espère limiter l'installation de suEXEC seulement par les administrateurs qui sont vraiment décidés à l'utiliser !
Toujours avec nous ? Oui ? Bien. Allons-y alors !
Avant de commencer à installer et configurer suEXEC, il nous faut tout d'abord expose le modèle de sécurité que vous êtes sur le point d'implémenter. Ce faisant, vous comprendrez mieux ce qui se passe réellement à l'intérieur de suEXEC et pourquoi certaines précautions sont nécessaires pour préserver la sécurité de votre système.
suEXEC
est basé sur un programme "lieur" setuid appelé par le serveur Apache principal. Ce programme est appelé lorsqu'une requête HTTP vise un programme CGI ou SSI que l'administrateur a désigné comme devant tourner sous un autre UID que celui du serveur. Lorsqu'une telle requête arrive, Apache donne à suEXEC le nom du programme, les identifiants de l'utilisateur et du groupe sous lesquels il doit s'exécuter.Ce "lieur" emploie la procédure suivante pour déterminer le succès ou l'échec de l'opération -- si l'une des conditions suivantes n'est pas vérifiée, le programme enregistre un échec en trace et termine en erreur, autrement il continuera son exécution :
Le "lieur" ne peut s'exécuter que si le nombre d'arguments donné est correct. Le format approprié pour chaque argument est connu d'Apache. Si le "lieur" ne reçoit pas le nombre attendu d'arguments, c'est soit qu'il est en train d'être piraté, ou qu'il y a un problème dans la portion de code suEXEC du binaire d'Apache.
Ceci pour s'assurer que celui qui appelle ce programme est un utilisateur répertorié du système.
Ou plutôt, cet utilisateur est-il l'utilisateur habilité à exécuter ce programme ? Un seul utilisateur (l'utilisateur sous lequel tourne Apache) peut exécuter le "lieur".
La spécification du programme contient elle un '/' en tête, ou un '..' ? Ceci n'est pas permis ; le programme cible doit être à l'intérieur de l'espace géré par Apache.
Existe t'il ?
Existe t'il ?
Actuellement, suEXEC ne permet pas à root d'exécuter des programmes CGI/SSI.
L'UID minimal est spécifié au moment de la configuration. Il permet de régler quel est l'UID le plus faible autorisé à exécuter des programmes CGI/SSI. Ceci est utile dans la mesure où il est d'usage courant de donner aux comptes systèmes des UID de faible valeur.
Actuellement, suEXEC ne permet pas au groupe root d'exécuter des programmes CGI/SSI.
Le GID minimal est spécifié au moment de la configuration. Il permet de régler quel est le GID le plus faible autorisé à exécuter des programmes CGI/SSI. Ceci est utile dans la mesure où il est d'usage courant de donner aux groupes systèmes des GID de faible valeur.
Il s'agit de la phase où le programme commute son propriétaire en changeant d'utilisateur et de groupe par appel aux primitives setuid et setgid. La liste des accès de groupe est de plus renseignée de tous les groupes dont l'utilisateur est membre.
S'il n'existe pas, il ne pourra (on s'en doute) pas contenir de fichiers.
Si la requête est dirigée vers une portion normale de l'espace serveur, pointe t'elle vers un sous-répertoire de la racine documents définie par DocumentRoot? Si la requête pointe un UserDir, la requête est-elle dirigée vers un sous répertoire de la racine documents de l'utilisateur ?
Nous ne souhaitons pas que ce répertoire soit ouvert aux autres utilisateurs en écriture ; seul le propriétaire du répertoire doit pouvoir en modifier le contenu.
S'il n'existe pas, on voit mal comment il pourrait être exécuté.
Nous souhaitons que personne ne puisse venir modifier le code du programme.
Nous ne souhaitons pas que ce programme puisse à son tour changer les UID/GID que nous avons désignés.
Ce programme appartient-il bien à l'utilisateur sous lequel nous souhaitons le voir tourner ?
suEXEC "nettoie" l'environnement processus en établissant une variable PATH (définie lors de la configuration) pour une exécution sécurisée ; les seules variables passées à cet environnement sont les variables qui auront été spécifiées dans une liste de passage (laquelle est également créée lors de la configuration).
A ce point suEXEC finit son exécution et donne la main au programme cible.
Ceci constitue le fonctionnement standard du modèle de sécurité défini pour le "lieur" suEXEC. Il est quelque peu astreignant et pourra résulter en de nouvelles limitations pour le design de programmes CGI/SSI, mais cela se justifie pour des raisons de contrôle de sécurité du système.
Pour plus d'informations sur comment ce modèle de sécurité limite limite vos possibilités en matière de configuration du serveur, ainsi que sur les risques de sécurité qu'une utilisation correcte de suEXEC peut faire éviter, consultez la rubrique "Les Gremlins peuvent entrer chez vous !" dans ce document.
C'est là que l'on commence à s'amuser. L'installation et la configuration de suEXEC est une procédure en quatre étapes : éditer le fichier d'en-tête de suEXEC, compiler suEXEC, placer le fichier binaire suEXEC à son emplacement approprié, et enfin configurer Apache pour utiliser suEXEC.
EDITION DE L'EN-TETE suEXEC
cd support [ENTER]
Editer le fichier suexec.h et modifiez les macros suivantes de façon à les adapter à votre installation Apache.
Dans support/suexec.h
/*
* HTTPD_USER -- Définit le nom d'utilisateur sous lequel Apache tourne en
* temps normal. C'est le seul utilisateur habilité à exécuter
* ce programme.
*/
#define HTTPD_USER "www"
/*
* UID_MIN -- Definit le plus faible UID permis pour l'utilisateur
* cible donné à suEXEC. Dans la plupart des cas, 500 ou 100 convient.
*/
#define UID_MIN 100
/*
* GID_MIN -- Definit le plus faible GID permis pour l'utilisateur
* cible donné à suEXEC. Dans la plupart des cas, 100 convient.
*/
#define GID_MIN 100
/*
* USERDIR_SUFFIX -- Definit le sous-répertoire relatif sous la racine
* du compte utilisateur auquel suEXEC a l'autorisation
* d'accès. Tous les exécutables dans ce répertoire
* pourront être lancés par suEXEC sous cet utilisateur
* et seront donc "sécurisés". Si vous utilisez une directive
* UserDir simple (c-à-d. une ou n'apparaît pas de
* "*"), cette étoile est implicite pour le répertoire
* spécifié. suEXEC ne fonctionnera pas correctement
* si la directive UserDir pointe vers un répertoire
* différent de celui défini comme répertoire de "login"
* pour cet utilisateu dans le fichier /etc/passwd.
*
* Si vous avez défini des VirtualHosts assignés à un
* UserDir différent pour chacun, vous aurez peut être besoin
* de rassembler tous les répertoires concernés dans un seul
* et unique répertoire père ; vous pouvez nommer ce répertoire
* père ici. SI CE PARAMETRE N'EST PAS CORRECTEMENT
* RENSEIGNE, LES REQUETES CGI POUR LES ~USERDIR
* N'ABOUTIRONT PAS !
* Voir la documentation de suEXEC pour plus d'informations.
*/
#define USERDIR_SUFFIX "public_html"
/*
* LOG_EXEC -- Definit le nom de fichier dans lequel toutes les
* transactions et erreurs générées par l'usage de suEXEC
* seront tracées.
*/
#define LOG_EXEC "/usr/local/apache/logs/cgi.log" /* Need me? */
/*
* DOC_ROOT -- Definit le DocumentRoot pour Apache. Ce sous-arbre
* sera le seul (à part ceux définis par chaque UserDirs)
* à pouvoir être utilisé par suEXEC.
*/
#define DOC_ROOT "/usr/local/apache/htdocs"
/*
* SAFE_PATH -- Definit un PATH d'environment sécurisé à passer aux exécutables CGI.
*
*/
#define SAFE_PATH "/usr/local/bin:/usr/bin:/bin"
COMPILATION DU "LIEUR" SUEXEC
cc suexec.c -o suexec [ENTER]. Cette opération crée l'exécutable suexec du "lieur".
COMPILATION D'APPACHE AVEC LE SUPPORT SUEXEC
Dans src/httpd.h
/* The path to the suEXEC wrapper */
#define SUEXEC_BIN "/usr/local/apache/sbin/suexec"
Si votre installation vous conduit à placer l'exécutable du lieur dans un répertoire différent, éditez le fichier src/httpd.h et recompilez votre serveur Apache. Voir Installer et compiler Apache pour plus d'informations quant à cette opération.
COPIE DU BINAIRE SUEXEC A SON EMPLACEMENT APPROPRIE
cp suexec /usr/local/apache/sbin/suexec [ENTER]
Pour permettre au "lieur" d'exécuter les translations d'UID/GID, il doit apparaître comme appartenant à l'utilisateur root et avoir le bit d'exécution setuserid marqué. Si vous n'êtes pas actuellement sous un shell root, exécutez les commandes suivantes :
chown root /usr/local/apache/sbin/suexec [ENTER]
chmod 4711 /usr/local/apache/sbin/suexec [ENTER]
Une fois l'exécutable suexec correctement compilé et installé, vous devez arrêter et redémarrer le serveur Apache. Une simple commande kill -1 `cat httpd.pid` n'est pas suffisante. Au démarrage du serveur Web, si Apache trouve un "lieur" suexec correctement configuré, il écrira l'information suivante sur le terminal :
Configuring Apache for use with suexec wrapper.
Si vous ne voyez pas apparaître ce message au démarrage du serveur, c'est que l'exécutable du "lieur" n'a certainement pas été trouvé là où Apache s'attendait à ce qu'il soit, ou cet exécutable n'est pas un programme setuid root. Vérifiez votre installation et recommencez.
L'une des façon d'utiliser suEXEC est avec les directives User et Group dans les sections VirtualHost. En renseignant ces directives avec des valeurs différentes des ID définis pour le serveur principal, toutes les requêtes dirigées vers ces ressources CGI seront exécutées sous l'Utilisateur et le Groupe définis dans cette section <VirtualHost>. Si seulement l'une de ces deux directives (ou aucune des deux) est spécifiée pour ce <VirtualHost> alors l'exécution est confiée à l'utilisateur et au groupe du serveur principal.
suEXEC
peut aussi être utilisé pour exécuter des programmes CGI au titre de l'utilisateur vers qui la requête est dirigée. Ceci est accompli en utilisant le caractère ~ comme préfixe de l'UID sous lequel l'exécution est désirée. Les seules contraintes sans lesquelles cette fonctionnalité ne marche pas est que l'exécution des CGI doit être autorisée pour cet utilisateur et que le script doit respecter les règles de sécurité ci-avant.Le "lieur" suEXEC inscrit des informations de trace dans le fichier spécifié dans le fichier suexec.h comme précisé plus haut. Si vous pensez avoir installé et configuré correctement le "lieur", consultez le fichier de trace généré et le fichier de trace d'erreur du serveur pour voir si vous pouvez aller vous reposer.
NOTE!
Cette section peut ne pas être exhaustive. Pour obtenir la dernière révision de cette section de la documentation, consultez la Documentation "en ligne" (US) officielle du groupe Apache.Il y a néanmoins quelques point intéressants à signaler quant aux limitations de configuration du serveur induites par l'utilisation de suEXEC. Nous vous prions de les lire avant de nous transmettre tout rapport de "bogues" concernant suEXEC.
Pour des raisons de sécurité et d'efficience, toutes les requêtes suEXEC doivent pointer à l'intérieur d'un répertoire tête lorsqu'elles sont dirigées vers un hôte virtuel, ou un répertoire tête DocumentRoot pour les requêtes vers des comptes utilisateurs. Par exemple, si vous configurez quatre VirtualHosts, vous structurerez toutes vos racines document VHosts en dehors de la hiérarchie des documents servis par Apache pour tirer tous les avantages de suEXEC utilisés pour les VirtualHosts. (Un exemple sera donné prochainement.)
Sa modification peut être assez dangereuse. Assurez vous que tous les répertoires que vous mentionnez dans ce "define" sont sûrs. Il ne s'agit pas que cette configuration permette à quiconque dans le monde de vous introduire un "cheval de troie".
De nouveau, cela peut causer un Enorme problème si vous essayez de modifier le code source sans savoir exactement ce que vous faites. Abstenez vous en le plus possible.
