Serveur Apache HTTP Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# 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é

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- 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 `PrivilegesMode`s 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.

## Directive DTracePrivileges

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.

## Directive PrivilegesMode

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.

## Directive VHostCGIMode

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`.

## Directive VHostCGIPrivs

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 !

## Directive VHostGroup

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`

## Directive VHostPrivs

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.

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 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 !

## Directive VHostSecure

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.

## Directive VHostUser

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é

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

- `User`
- `SuexecUserGroup`

Langues Disponibles: en | fr

## 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.