Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
| 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 |
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.
DTracePrivileges PrivilegesMode VHostCGIMode VHostCGIPrivs VHostGroup VHostPrivs VHostSecure VHostUser
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 supportant 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 supportant 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 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).
<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
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.
| 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.
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 (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.
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: | VHostUser 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 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 :
# 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.