Module Apache mod_privileges

Langues Disponibles: en | + fr

+ + + + +

Description:	Support 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

Sommaire

+ +

Ce module permet l'exécution de différents serveurs virtuels sous +différents identifiants Unix User 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 User/Group pour chaque +requête dans un même processus. Il n'est donc pas compatible avec +les MPM threadés, et refusera de s'exécuter en cas d'utilisation d'un de +ces derniers.

+ +

mod_privileges traite des problèmes de sécurité +similaires à ceux de 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.

+ +

Sujets

Considérations à propos de sécurité

Commentaires

Considérations à propos de sécurité

+ +

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 :

+ + +

L'exécution sous un utilisateur système pose les mêmes problèmes +de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et +suphp.
Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes +utilisés par mod_privileges, +pourrait élever ses privilèges à tout niveau +accessible au processus httpd dans tout serveur virtuel. Ceci introduit +de nouveaux risques si (et seulement si) mod_privileges est compilé avec +l'option BIG_SECURITY_HOLE.
Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes +utilisés par mod_privileges, +pourrait élever ses privilèges pour s'attribuer +l'identifiant utilisateur d'un autre utilisateur (et/ou groupe) +système.

+ +

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.

Mode FAST: En mode FAST, les requêtes sont traitées "in-process" +avec les uid/gid et privilèges sélectionnés, si bien que la +surcharge est négligeable. Ceci convient aux situations "Benign", mais +n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un +module ou script "in-process".
Mode SECURE: Une requête en mode SECURE génère un sous-processus qui +supprime les privilèges. Ce comportement est très similaire à +l'exécution d'un programme CGI avec suexec, mais il reste valable tout +au long du cycle de traitement de la requête, avec en plus l'avantage +d'un contrôle précis des privilèges.

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 supportant les privilèges avant le +début du cycle de traitement de la requête.

+ +

DTracePrivileges Directive

+ + + + + + + + +

Description:	Détermine si les privilèges requis par dtrace sont +activés.
Syntaxe:	`DTracePrivileges On\|Off`
Défaut:	`DTracePrivileges Off`
Contexte:	configuration du serveur
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.

+ +

PrivilegesMode Directive

+ + + + + + + + +

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 supportant les privilèges.
Syntaxe:	`PrivilegesMode FAST\|SECURE\|SELECTIVE`
Défaut:	`PrivilegesMode FAST`
Contexte:	configuration du serveur, 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 supportant +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).

Avertissement

+ Lorsque le mode SELECTIVE a été défini pour un serveur virtuel, + l'activation des privilèges doit être reportée après + la détermination, par la phase de comparaison du traitement de + la requête, du contexte <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. +

+ +

VHostCGIMode Directive

+ + + + + + + + +

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 + mod_cgi, ni des programmes externes similaires tels + que ceux créés via le module mod_ext_filter ou les + programmes de réécriture externes utilisés par la directive + 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.

+ +

VHostCGIPrivs Directive

+ + + + + + + + +

Description:	Assigne des privilèges au choix aux sous-processus créés +par 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 (`prefork` ou MPM +personnalisé) et lorsque `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 + 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 refuser 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.

+ +

Sécurité

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 !

+ +

VHostGroup Directive

+ + + + + + + + +

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 +Group`
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 :

Un nom de groupe: Fait référence au groupe donné par son nom.
# suivi d'un numéro de groupe.: Fait référence au groupe donné par son numéro.

+ +

Sécurité

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.

+ +

Voir aussi

Group
SuexecUserGroup

VHostPrivs Directive

+ + + + + + + + +

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 (`prefork` ou MPM +personnalisé) et lorsque `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.

+ +

Sécurité

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 !

+ +

VHostSecure Directive

+ + + + + + + + +

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.

Note

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.

+ +

VHostUser Directive

+ + + + + + + + +

Description:	Définit l'identifiant utilisateur sous lequel s'exécute un +serveur virtuel.
Syntaxe:	`VHostUser identifiant-utilisateur-unix`
Défaut:	`Hérite de l'identifiant utilisateur spécifié par la directive +User`
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 VHostUser 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 :

Un nom d'utilisateur: Fait référence à l'utilisateur donné par son nom.
# suivi d'un numéro d'utilisateur.: Fait référence à l'utilisateur donné par son numéro.

+ +

Sécurité

+ +

Voir aussi

User
SuexecUserGroup

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.