Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
Langues Disponibles: fr
| Description: | des privilèges de Solaris et de l'exécution des serveurs virtuels sous différents identifiants utilisateurs. |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | privileges_module |
| Fichier Source: | mod_privileges.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache sur les plates-formes Solaris 10 et OpenSolaris |
Ce module permet l'exécution de différents serveurs virtuels sous différents identifiants Unix et Group, et avec différents Privilèges Solaris. En particulier, il apporte au problème de séparation des privilèges entre les différents serveurs virtuels la solution que devait apporter le module MPM abandonné perchild. Il apporte aussi d'autres améliorations en matière de sécurité.
À la différence de perchild, mod_privileges n'est pas un module MPM. Il travaille au sein d'un modèle de traitement pour définir les privilèges et les /Group pour chaque requête dans un même processus. Il n'est donc pas compatible avec les MPM threadés, et refa de s'exécuter en cas d'utilisation d'un de ces derniers.
suexec ; mais à la différence de ce dernier, il ne s'applique pas seulement aux programmes CGI, mais à l'ensemble du cycle de traitement d'une requête, y compris les applications in-process et les sous-processus. Il convient particulièrement à l'exécution des applications PHP sous mod_php, qui est lui-même incompatible avec les modules MPM threadés. Il est également bien adapté aux autres applications de type script in-process comme mod_perl, mod_python, et mod_ruby, ainsi qu'aux applications en langage C telles que les modules Apache pour lesquels la séparation des privilèges constitue un problème.
mod_privileges introduit de nouveaux problèmes de sécurité dans les situations où du code non sûr peut s'exécuter à l'intérieur du processus du serveur web. Ceci s'applique aux modules non sûrs, et aux scripts s'exécutant sous des modules comme mod_php ou mod_perl. Les scripts s'exécutant en externe (comme par exemple les scripts CGI ou ceux s'exécutant sur un serveur d'applications derrière mod_proxy ou mod_jk) ne sont pas concernés.
Les principaux problèmes de sécurité que l'on rencontre avec mod_privileges sont :
La directive PrivilegesMode vous permet de sélectionner soit le mode FAST, soit le mode SECURE. Vous pouvez panacher les modes en utilisant par exemple le mode FAST pour les utilisateurs de confiance et les chemins contenant du code entièrement audité, tout en imposant le mode SECURE où un utilisateur non sûr a la possibilité d'introduire du code.
Avant de décrire les modes, il nous faut présenter les cas d'utilisation de la cible : "Benign" ou "Hostile". Dans une situation "Benign", vous voulez séparer les utilisateurs pour leur confort, et les protéger, ainsi que le serveur, contre les risques induits par les erreurs involontaires. Dans une situation "Hostile" - par exemple l'hébergement d'un site commercial - il se peut que des utilisateurs attaquent délibérément le serveur ou s'attaquent entre eux.
Vous pouvez sélectionner différents PrivilegesModes pour chaque serveur virtuel, et même dans un contexte de répertoire à l'intérieur d'un serveur virtuel. Le mode FAST convient lorsque les utilisateurs sont sûrs et/ou n'ont pas le privilège de charger du code "in-process". Le mode SECURE convient dans les cas où du code non sûr peut s'exécuter "in-process". Cependant, même en mode SECURE, il n'y a pas de protection contre un utilisateur malveillant qui a la possibilité d'introduire du code ant les privilèges avant le début du cycle de traitement de la requête.
| Description: | Détermine si les privilèges requis par dtrace sont activés. |
|---|---|
| Syntaxe: | DTracePrivileges On|Off |
| Défaut: | DTracePrivileges Off |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | >Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (prefork ou MPM personnalisé). |
Cette directive qui s'applique à l'ensemble du serveur permet de déterminer si Apache s'exécutera avec les privilèges requis pour exécuter dtrace. Notez que la définition DTracePrivileges On n'activera pas à elle-seule DTrace, mais que DTracePrivileges Off l'empêchera de fonctionner.
| Description: | Fait un compromis entre d'une part l'efficacité et la vitesse de traitement et d'autre part la sécurité à l'encontre des codes malicieux ant les privilèges. |
|---|---|
| Syntaxe: | PrivilegesMode FAST|SECURE|SELECTIVE |
| Défaut: | PrivilegesMode FAST |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec des modules MPMs non threadés (comme prefork ou un module personnalisé). |
Cette directive permet de faire un compromis entre les performances et la sécurité à l'encontre des codes malicieux ant les privilèges. En mode SECURE, chaque requête est traitée dans un sous-processus sécurisé, ce qui induit une dégradation sensible des performances. En mode FAST, le serveur n'est pas protégé contre l'augmentation de privilège comme décrit plus haut.
Cette directive est sensiblement différente selon qu'elle se trouve dans une section <Directory> (ou Location/Files/If) ou au niveau global ou dans un <VirtualHost>.
Au niveau global, elle définit un comportement par défaut dont hériteront les serveurs virtuels. Dans un serveur virtuel, les modes FAST ou SECURE agissent sur l'ensemble de la requête HTTP, et toute définition de ces modes dans une section <Directory> sera ignorée. Le pseudo-mode SELECTIVE confie le choix du mode FAST ou SECURE aux directives contenues dans une section<Directory>.
Dans une section <Directory>, elle ne s'applique que lorsque le mode SELECTIVE a été défini pour le serveur virtuel. Seuls FAST ou SECURE peuvent être définis dans ce contexte (SELECTIVE n'aurait pas de sens).
<Directory> qui s'applique à la requête. Ceci peut donner à un attaquant l'opportunité d'introduire du code via une directive RewriteMap s'exécutant au niveau global ou d'un serveur virtuel avant que les privilèges n'aient été supprimés et l'uid/gid défini.
| Description: | Détermine si le serveur virtuel peut exécuter des sous-processus, et définit les privilèges disponibles pour ces dernier. |
|---|---|
| Syntaxe: | VHostCGIMode On|Off|Secure |
| Défaut: | VHostCGIMode On |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (prefork ou MPM personnalisé). |
Détermine si le serveur virtuel est autorisé à exécuter fork et exec, et définit les privilèges requis pour exécuter des sous-processus. Si cette directive est définie à Off le serveur virtuel ne disposera d'aucun privilège et ne pourra exécuter ni des programmes ou scripts CGI classiques via le module traditionnel RewriteMap. Notez que ceci n'empêche pas l'exécution de programmes CGI via d'autres processus et sous d'autres modèles de sécurité comme mod_fcgid, ce qui est la solution recommandée sous Solaris.
Si cette directive est définie à On ou Secure, le serveur virtuel pourra exécuter les scripts et programmes externes cités ci-dessus. Définir la directive VHostCGIMode à Secure a pour effet supplémentaire de n'accorder aucun privilège aux sous-processus, comme décrit dans la directive VHostSecure.
| Description: | Assigne des privilèges au choix aux sous-processus créés par un serveur virtuel. |
|---|---|
| Syntaxe: | VHostCGIPrivs [+-]?privilege-name [[+-]?privilege-name] ... |
| Défaut: | Aucun |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (mod_privileges est construit avec l'option de compilation BIG_SECURITY_HOLE. |
La directive VHostCGIPrivs permet d'assigner des privilèges au choix aux sous-processus créés par un serveur virtuel, comme décrit dans la directive VHostCGIMode. Chaque privilege-name correspond à un privilège Solaris tel que file_setid ou sys_nfs.
privilege-name peut être éventuellement préfixé par + ou -, ce qui va respectivement accorder ou ref le privilège. Si nom-privilège est spécifié sans + ni -, tous les autres privilèges préalablement assignés au serveur virtuel seront refusés. Cette directive permet de construire aisément votre propre jeu de privilèges en annulant tout réglage par défaut.
L'utilisation de cette directive peut ouvrir d'immenses trous de sécurité dans les sous-processus Apache, jusqu'à leur exécution avec les droits de root. Ne l'utilisez que si vous êtes absolument sûr de comprendre ce que vous faites !
| Description: | Définit l'identifiant du groupe sous lequel s'exécute un serveur virtuel. |
|---|---|
| Syntaxe: | VHostGroup identifiant-groupe-unix |
| Défaut: | Hérite de l'identifiant du groupe spécifié par la directive |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (prefork ou MPM personnalisé). |
La directive VHostGroup permet de définir l'identifiant du groupe unix sous lequel le serveur va traiter les requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant du groupe est défini avant le traitement de la requête, puis restauré à sa valeur de départ via les Privilèges Solaris. Comme la définition s'applique au processus, cette directive est incompatible avec les modules MPM threadés.
Unix-group peut être :
# suivi d'un numéro de groupe.
Cette directive ne peut pas être utilisée pour exécuter Apache en tant que root ! Elle est tout de même susceptible de poser des problèmes de sécurité similaires à ceux décrits dans la documentation de suexec.
| Description: | Assigne des privilèges à un serveur virtuel. |
|---|---|
| Syntaxe: | VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... |
| Défaut: | Aucun |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (mod_privileges est construit avec l'option de compilation BIG_SECURITY_HOLE. |
La directive VHostPrivs permet d'assigner des privilèges au choix à un serveur virtuel. Chaque nom-privilège correspond à un privilège Solaris tel que file_setid ou sys_nfs.
nom-privilège peut être éventuellement préfixé par + ou -, ce qui va respectivement accorder ou ref le privilège. Si nom-privilège est spécifié sans + ni -, tous les autres privilèges préalablement assignés au serveur virtuel seront refusés. Cette directive permet de construire aisément votre propre jeu de privilèges en annulant tout réglage par défaut.
L'utilisation de cette directive peut ouvrir d'immenses trous de sécurité dans Apache, jusqu'au traitement de requêtes avec les droits de root. Ne l'utilisez que si vous êtes absolument sûr de comprendre ce que vous faites !
| Description: | Détermine si le serveur s'exécute avec une sécurité avancée pour les serveurs virtuels. |
|---|---|
| Syntaxe: | VHostSecure On|Off |
| Défaut: | VHostSecure On |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (prefork ou MPM personnalisé). |
Détermine si les serveurs virtuels traitent les requêtes avec une sécurité avancée en supprimant les Privilèges rarement requis par un serveur web, mais disponibles par défaut pour un utilisateur Unix standard, et donc susceptibles d'être demandés par des modules et des applications. Il est recommandé de conserver la définition par défaut (On), sauf si elle empêche une application de fonctionner. Comme la définition s'applique au processus, cette directive est incompatible avec les modules MPM threadés.
Le fait que la directive VHostSecure empêche une application de fonctionner peut constituer un signal d'avertissement indiquant que la sécurité de l'application doit être revue.
| Description: | Définit l'identifiant utilisateur sous lequel s'exécute un serveur virtuel. |
|---|---|
| Syntaxe: | VHost identifiant-utilisateur-unix |
| Défaut: | Hérite de l'identifiant utilisateur spécifié par la directive |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les modules MPM non-threadés (prefork ou MPM personnalisé). |
La directive VHost permet de définir l'identifiant utilisateur unix sous lequel le serveur va traiter les requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant utilisateur est défini avant le traitement de la requête, puis restauré à sa valeur de départ via les Privilèges Solaris. Comme la définition s'applique au processus, cette directive est incompatible avec les modules MPM threadés.
identifiant-utilisateur-unix peut être :
# suivi d'un numéro d'utilisateur.
Cette directive ne peut pas être utilisée pour exécuter Apache en tant que root ! Elle est tout de même susceptible de poser des problèmes de sécurité similaires à ceux décrits dans la documentation de suexec.
Langues Disponibles: fr