mod_privileges Support des privilèges de Solaris et de l'exécution des serveurs virtuels sous différents identifiants utilisateurs. Experimental mod_privileges.c privileges_module 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.
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 :

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.

PrivilegesMode 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. PrivilegesMode FAST|SECURE|SELECTIVE PrivilegesMode FAST server config virtual host directory 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. VHostUser Définit l'identifiant utilisateur sous lequel s'exécute un serveur virtuel. VHostUser identifiant-utilisateur-unix Hérite de l'identifiant utilisateur spécifié par la directive User virtual host 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.

 User SuexecUserGroup VHostGroup Définit l'identifiant du groupe sous lequel s'exécute un serveur virtuel. VHostGroup identifiant-groupe-unix Hérite de l'identifiant du groupe spécifié par la directive Group virtual host 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.

 Group SuexecUserGroup VHostSecure Détermine si le serveur s'exécute avec une sécurité avancée pour les serveurs virtuels. VHostSecure On|Off VHostSecure On virtual host 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.

 VHostCGIMode Détermine si le serveur virtuel peut exécuter des sous-processus, et définit les privilèges disponibles pour ces dernier. VHostCGIMode On|Off|Secure VHostCGIMode On virtual host 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.

 DTracePrivileges Détermine si les privilèges requis par dtrace sont activés. DTracePrivileges On|Off DTracePrivileges Off server config >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.

 VHostPrivs Assigne des privilèges à un serveur virtuel. VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... Aucun virtual host 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 !

 VHostCGIPrivs Assigne des privilèges au choix aux sous-processus créés par un serveur virtuel. VHostCGIPrivs [+-]?privilege-name [[+-]?privilege-name] ... Aucun virtual host 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.

privilege-name peut être éventuellement préfixé par + ou -, ce qui va respectivement accorder ou refuser le privilège. Si privilege-name 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 !