diff options
Diffstat (limited to 'fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml')
| -rw-r--r-- | fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml | 178 |
1 files changed, 89 insertions, 89 deletions
diff --git a/fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml b/fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml index 0268a2e244..272c1899cf 100644 --- a/fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml +++ b/fr_FR.ISO8859-1/books/developers-handbook/secure/chapter.sgml @@ -2,7 +2,7 @@ <!-- The FreeBSD Documentation Project The FreeBSD French Documentation Project - + $Id: chapter.sgml,v 1.1 2002-02-14 14:25:02 gioria Exp $ Original revision: 1.3 $FreeBSD$ @@ -15,7 +15,7 @@ <para>Ce chapître a été écrit par Murray Stokely.</para> <sect1><title>Synopsis</title> - + <para>Ce chapître décrit quelques problèmes de sécurité qui ont tourmenté les programmeurs Unix depuis des dizaines d'années et quelques uns des nouveaux outils disponibles pour aider @@ -28,7 +28,7 @@ <para>Ecrire des applications sécurisées demande une très minutieuse et pessimiste vision de la vie. Les applications devrait fonctionner - avec le principe du <quote>privilège moindre</quote> de façon à ce + avec le principe du <quote>privilège moindre</quote> de façon à ce qu'aucun processus ne fonctionne avec plus que le strict minimum dont il a besoin pour accomplir sa tâche. Le code pré-testé devrait être réutilisé autant que possible pour éviter les erreurs communes que @@ -39,49 +39,49 @@ Les applications ne devraient jamais avoir confiance dans la saisie de l'utilisateur (sous toutes ses formes), les ressources système, la communication inter-processus, ou l'enchaînement - des évènements. Les processus Unix n'exécutent pas de manière synchrone + des évènements. Les processus Unix n'exécutent pas de manière synchrone aussi, logiquement, les opérations sont rarement atomiques.</para> </sect1> - <sect1><title>Dépassement de capacité</title> + <sect1><title>Dépassement de capacité</title> <para>Les dépassements de capacité ("Buffer Overflows") existent depuis les débuts de l'architecture de Von-Neuman <xref linkend="COD"/>. Ils gagnèrent une grande notoriété en 1988 avec le ver pour Internet de Morris. Malheureusement, la même attaque basique reste effective aujourd'hui. Des 17 rapports de sécurité du CERT de 1999, 10 - furent causés directement des bogues logiciels de dépassement de + furent causés directement des bogues logiciels de dépassement de capacité. De loin la plus commune de types d'attaques par dépassement de capacité est basée sur la corruption de la pile.</para> - <para>La plupart des systèmes informatiques modernes utilise une pile + <para>La plupart des systèmes informatiques modernes utilise une pile pour passer les arguments aux procédures et stocker les variables locales Une pile est une zone mémoire dernier entré-premier sorti (Last In-First - Out : LIFO) dans la zone de mémoire haute de l'image d'un processus. - Quand un programme invoque une fonction une nouvelle structure pile est - créée. Cette structure pile consiste dans les arguments passés à la + Out : LIFO) dans la zone de mémoire haute de l'image d'un processus. + Quand un programme invoque une fonction une nouvelle structure pile est + créée. Cette structure pile consiste dans les arguments passés à la fonction aussi bien que dans une quantité dynamique d'espace pour la variable locale. Le pointeur de pile est un registre qui référence la position courante du sommet de la pile. Etant donné que cette valeur - change constamment au fur et à mesure que de nouvelles valeurs sont + change constamment au fur et à mesure que de nouvelles valeurs sont ajoutées au sommet de la pile, beaucoup d'implémentations fournissent aussi un pointeur de structure qui est positionné dans le voisinage du début de la structure pile de façon à ce que les variables locales soient plus facilement adressables relativement à cette valeur. <xref linkend="COD"/> L'adresse de retour des appels de fonction est aussi - stocké dans la pile, et cela est la cause des découvertes des + stocké dans la pile, et cela est la cause des découvertes des dépassements de pile puisque faire déborder une variable locale dans une fonction peut écraser l'adresse de retour de cette fonction, permettant potentiellement à un utilisateur malveillant d'exécuter le code qu'il ou elle désire.</para> - <para>Bien que les attaques basées sur les dépassements de pile soient + <para>Bien que les attaques basées sur les dépassements de pile soient de loin les plus communes, il serait aussi possible de faire exploser la pile avec une attaque du tas (malloc/free).</para> <para>Le langage de programmation C ne réalise pas de vérifications automatiques des limites sur les tableaux ou pointeurs comme d'autres - langages le font. De plus, la librairie standard du C est remplie d'une + langages le font. De plus, la librairie standard du C est remplie d'une poignée de fonctions très dangereuses.</para> <informaltable> @@ -142,7 +142,7 @@ int main() { int i=0; while ((buffer[i++] = getchar()) != '\n') {}; - + i=1; manipulate(buffer); i=2; @@ -150,9 +150,9 @@ int main() { return 0; }</programlisting> - <para>Examinons quel serait l'aspect de l'image mémoire de ce processus - si nous avions entré 160 espaces dans notre petit programme avant - d'appuyer sur <keycap>Entrée</keycap>.</para> + <para>Examinons quel serait l'aspect de l'image mémoire de ce processus + si nous avions entré 160 espaces dans notre petit programme avant + d'appuyer sur <keycap>Entrée</keycap>.</para> <para>[XXX Schéma ici!]</para> @@ -165,28 +165,28 @@ int main() { <para>La solution la plus simple au problème de débordement de pile est de toujours utiliser de la mémoire restreinte en taille et les fonctions de copie de chaîne de caractères. <function>strncpy</function> - et <function>strncat</function> font parties de la libraire standard du + et <function>strncat</function> font parties de la libraire standard du C. Ces fonctions acceptent une valeur de longueur comme paramètre qui - qui ne devrait pas être plus grande que la taille du tampon de + qui ne devrait pas être plus grande que la taille du tampon de destination. Ces fonctions vont ensuite copier `taille' octets de la - source vers la destination. Toutefois, il y a un certain nombre de + source vers la destination. Toutefois, il y a un certain nombre de problèmes avec ces fonctions. Aucune fonction ne garantit une terminaison - par le caractère NULL si la taille du tampon d'entrée est aussi grand + par le caractère NULL si la taille du tampon d'entrée est aussi grand que celui de destination. Le paramètre taille est aussi utilisé de façon illogique entre <function>strncpy</function> et <function>strncat</function> aussi il est facile pour les programmeurs d'être déroutés sur leur - utilisation convenable. Il y a aussi une perte significative des - performances comparé à <function>strcpy</function> lorsque l'on copie - une courte chaîne dans un grand tampon puisque <function>strncpy</function> + utilisation convenable. Il y a aussi une perte significative des + performances comparé à <function>strcpy</function> lorsque l'on copie + une courte chaîne dans un grand tampon puisque <function>strncpy</function> remplit de caractères NULL jusqu'à la taille spécifiée.</para> - <para>Dans OpenBSD, une autre implémentation de la copie de mémoire + <para>Dans OpenBSD, une autre implémentation de la copie de mémoire a été créée pour contourner ces problèmes. Les fonctions <function>strlcpy</function> - et <function>strlcat</function> garantissent qu'elles termineront + et <function>strlcat</function> garantissent qu'elles termineront toujours le tampon de destination par un caractère NULL losque l'argument - de taille est différent de zéro. Pour plus d'informations sur ces + de taille est différent de zéro. Pour plus d'informations sur ces fonctions, voir <xref linkend="OpenBSD"/>. Les fonctions <function>strlcpy</function> et - <function>strlcat</function> d'OpenBSD ont été inclues dans FreeBSD + <function>strlcat</function> d'OpenBSD ont été inclues dans FreeBSD depuis la version 3.5.</para> <sect3><title>V#233;rifications des limites en fonctionnement basées sur le compilateur</title> @@ -194,26 +194,26 @@ int main() { <para>Malheureusement il y a toujours un très important assortiment de code en utilisation publique qui copie aveuglément la mémoire sans - utiliser une des routines de copie limitée dont nous venons juste de + utiliser une des routines de copie limitée dont nous venons juste de discuter. Heureusement, il y a une autre solution. Plusieurs produits - complémentaires pour compilateur et librairies existent pour faire - de la vérification de limites pendant le fonctionnement en C/C++.</para> + complémentaires pour compilateur et librairies existent pour faire + de la vérification de limites pendant le fonctionnement en C/C++.</para> - <para>StackGuard est un de ces produits qui est implémenté comme un - petit correctif ("patch") pour le générateur de code gcc. Extrait du + <para>StackGuard est un de ces produits qui est implémenté comme un + petit correctif ("patch") pour le générateur de code gcc. Extrait du site Internet de StackGuard, http://immunix.org/stackguard.html : - <blockquote><para>"StackGuard détecte et fait échouer les attaques + <blockquote><para>"StackGuard détecte et fait échouer les attaques par débordement de pile en empêchant l'adresse de retour sur la pile - d'être altérée. StackGuard place un mot "canari" + d'être altérée. StackGuard place un mot "canari" <footnote><para>NDT : Jaune de préférence pour être bien visible</para></footnote> à côté de l'adresse de retour quand la fontion est appelée. Si le mot "canari" a été altéré au retour de la fonction, alors une attaque par débordement de pile a été tentée et le programme répond en envoyant - une alerte d'intrusion dans la trace système (syslog) et - s'arrête alors."</para></blockquote> + une alerte d'intrusion dans la trace système (syslog) et + s'arrête alors."</para></blockquote> <blockquote><para>"StackGuard est implémenté comme un petit correctif - au générateur de code gcc, spécifiquement sur les routines + au générateur de code gcc, spécifiquement sur les routines function_prolog() et function_epilog(). function_prolog() a été amélioré pour laisser des "canaris" sur la pile quand les fonctions démarrent, et function_epilog vérifie l'intégrité des "canaris" quand @@ -222,14 +222,14 @@ int main() { </para> <para>Recompiler votre application avec StackGuard est un - moyen efficace pour stopper la plupart des attques par dépassement de + moyen efficace pour stopper la plupart des attques par dépassement de capacité, mais cela peut toujours être compromis.</para> </sect3> <sect3><title>Vérifications des limites en fonctionnement basées sur les librairies</title> - <para>Les mécanismes basés sur le compilateur sont totalement inutiles + <para>Les mécanismes basés sur le compilateur sont totalement inutiles pour logiciel seulement binaire que vous ne pouvez recompiler. Pour ces situations, il existe un nombre de librairies qui re-implémente les fonctions peu sûres de la librairie C @@ -245,8 +245,8 @@ int main() { <para>Malheureusement ces défenses basées sur les librairies possèdent un certain nombre de défauts. Ces librairies protègent seulement d'un - très petit ensemble de problèmes liés à la sécurité et oublient de - réparer le problème actuel. Ces défenses peuvent échouer si + très petit ensemble de problèmes liés à la sécurité et oublient de + réparer le problème actuel. Ces défenses peuvent échouer si l'application a été compilée avec -fomit-frame-pointer. De même, les variables d'environnement LD_PRELOAD et LD_LIBRARY_PATH peuvent être réécrites/non définies par l'utilisateur.</para> @@ -257,25 +257,25 @@ int main() { <sect1><title>Les problèmes liés à SetUID</title> - <para>Il y a au moins 6 differents ID (identifiants) associés à un + <para>Il y a au moins 6 differents ID (identifiants) associés à un processus donné. A cause de cela, vous devez être très attentif avec l'accès que votre processus possède à un instant donné. En particulier, - toutes les applications ayant reçu des privilèges par seteuid doivent + toutes les applications ayant reçu des privilèges par seteuid doivent les abandonnés dès qu'ils ne sont plus nécessaires.</para> <para>L'identifiant de l'utilisateur réel (real user ID) peut seulement - être changé par un processus super-utilisateur. Le programme <application>login</application> - met celui à jour quand un utilisateur se connecte et il est rarement + être changé par un processus super-utilisateur. Le programme <application>login</application> + met celui à jour quand un utilisateur se connecte et il est rarement changé.</para> <para>L'identifiant de l'utilisateur effectif (effective user ID) est mis - à jour par les fonctions <function>exec()</function> si un programme + à jour par les fonctions <function>exec()</function> si un programme possède son bit seteuid placé. Une application peut appeler <function>seteuid()</function> à n'importe quel moment pour règler - l'identifiant de l'utilisateur effectif sur l'identifiant d'un + l'identifiant de l'utilisateur effectif sur l'identifiant d'un utilisateur réel ou sur le "set-user-ID" sauvé. - Quand l'identifiant de l'utilisateur effectif est placé par les - fonctions <function>exec()</function>, la valeur précédente est sauvée + Quand l'identifiant de l'utilisateur effectif est placé par les + fonctions <function>exec()</function>, la valeur précédente est sauvée dans le "set-user-ID" sauvé.</para> </sect1> @@ -285,46 +285,46 @@ int main() { <para>La méthode traditionnelle pour restreindre l'accès d'un processus se fait avec l'appel système <function>chroot()</function>. Cet appel système change le répertoire racine depuis lequel tous les autres chemins - sont référencés pour un processus et ses fils. Pour que cet appel + sont référencés pour un processus et ses fils. Pour que cet appel réussisse, le processus doit avoir exécuté (recherché) la permission dans le répertoire référencé. Le nouvel environnement - environment ne prend pas effet que lorsque vous appelez <function>chdir()</function> - dans celui-ci. + environment ne prend pas effet que lorsque vous appelez <function>chdir()</function> + dans celui-ci. Il doit être aussi noté qu'un processus peut facilement s'échapper d'un environnement chroot s'il a les privilèges du super-utilisateur. - Cela devrait être accompli en créant des fichiers spéciaux de - périphérique pour la mémoire du noyau, en attachant un dévermineur à un - processus depuis l'extérieur de sa "prison", ou par d'autres manières + Cela devrait être accompli en créant des fichiers spéciaux de + périphérique pour la mémoire du noyau, en attachant un dévermineur à un + processus depuis l'extérieur de sa "prison", ou par d'autres manières créatrices.</para> - + <para>Le comportement de l'appel système <function>chroot()</function> - peut être un peu contrôlé avec la commande <command>sysctl</command> et - la variable kern.chroot_allow_open_directories. - Quand cette valeur est règlée à 0, <function>chroot()</function> échouera + peut être un peu contrôlé avec la commande <command>sysctl</command> et + la variable kern.chroot_allow_open_directories. + Quand cette valeur est règlée à 0, <function>chroot()</function> échouera avec EPERM s'il y a un répertoire d'ouvert. Si la variable est règlée sur - la valeur par défaut 1, alors <function>chroot()</function> échouera - avec EPERM s'il y a un répertoire d'ouvert et que le processus est déjà - sujet à un appel <function>chroot()</function>. Pour toute autre valeur, la + la valeur par défaut 1, alors <function>chroot()</function> échouera + avec EPERM s'il y a un répertoire d'ouvert et que le processus est déjà + sujet à un appel <function>chroot()</function>. Pour toute autre valeur, la vérification des répertoires ouverts sera totalement court-circuitée.</para> <sect2><title>La fonctionnalité "prison" de FreeBSD</title> <para>Le concept de Prison ("Jail") étend <function>chroot()</function> en limitant les droits du - super-utilisateur pour créer un véritable `serveur virtuel'. Une fois - qu'une prison est mise en place, toute communication réseau doit avoir lieu - au travers de l'adresse IP spécifiée, et le droit du + super-utilisateur pour créer un véritable `serveur virtuel'. Une fois + qu'une prison est mise en place, toute communication réseau doit avoir lieu + au travers de l'adresse IP spécifiée, et le droit du "privilège super-utilisateur" dans cette prison est sévèrement gêné.</para> - <para>Tant qu'il se trouve en prison, tout test avec les droits du - super-utilisateur dans le noyau au travers d'un appel à + <para>Tant qu'il se trouve en prison, tout test avec les droits du + super-utilisateur dans le noyau au travers d'un appel à <function>suser()</function> échouera. Toutefois, quelques appels à <function>suser()</function> ont été changés par la nouvelle interface <function>suser_xxx()</function>. Cette fonction est responsable de fournir ou de retirer les accès aux droits du super-utilisateur pour les processus emprisonnés.</para> - <para>Un processus super-utilisateur dans un environnement emprisonné + <para>Un processus super-utilisateur dans un environnement emprisonné a le pouvoir de : </para> <itemizedlist> <listitem><simpara>Manipuler les identitifications avec @@ -339,16 +339,16 @@ int main() { <listitem><simpara>Règler les paramètres d'un noeud virtuel (vnode): <function>chflags</function>, <function>fchflags</function></simpara></listitem> - <listitem><simpara>Règler les attributs d'un noeud virtuel comme - les permissions d'un fichier, le propriétaire, le groupe, la taille, + <listitem><simpara>Règler les attributs d'un noeud virtuel comme + les permissions d'un fichier, le propriétaire, le groupe, la taille, la date d'accès, et la date de modification.</simpara></listitem> <listitem><simpara>Se lier à des ports privilégiés sur Internet (ports < 1024)</simpara></listitem> </itemizedlist> - <para><function>Jail</function> est un outil très utile pour exécuter + <para><function>Jail</function> est un outil très utile pour exécuter des applications dans un environnement sécurisé mais il a des - imperfections. Actuellement, les mécanismes IPC (Inter-Process + imperfections. Actuellement, les mécanismes IPC (Inter-Process Communications) n'ont pas été convertis pour utiliser <function>suser_xxx</function> aussi des applications comme MySQL ne peuvent être exécutée dans une prison. L'accès super-utilisateur peut avoir un sens très limité dans une prison, @@ -358,7 +358,7 @@ int main() { <sect2><title>Les capacitès des processus POSIX.1e</title> - <para>Posix a réalisé un document de travail qui ajoute l'audit + <para>Posix a réalisé un document de travail qui ajoute l'audit d'évènement, les listes de contrôle d'accès, les privilèges fins, l'étiquetage d'information, et le contrôle d'accès mandaté.</para> <para>Il s'agit d'un travail en cours et c'est l'objectif du projet <ulink @@ -373,15 +373,15 @@ int main() { <sect1><title>La confiance</title> <para>Une application ne devrait jamais supposer que tout est sain - dans l'environnement des utilisateurs. Cela inclut (mais n'est - certainement pas limité à) : la saisie de l'utilisateur, les signaux, - les variables d'environnement, les ressources, les communication - inter-processus, les mmaps, le répertoire de travail du système de - fichiers, les descripteurs de fichier, le nombre de fichiers ouverts, + dans l'environnement des utilisateurs. Cela inclut (mais n'est + certainement pas limité à) : la saisie de l'utilisateur, les signaux, + les variables d'environnement, les ressources, les communication + inter-processus, les mmaps, le répertoire de travail du système de + fichiers, les descripteurs de fichier, le nombre de fichiers ouverts, etc.</para> <para>Vous ne devriez jamais supposer que vous pouvez gérer toutes les - formes de saisie invalide qu'un utilisateur peut entrer. Votre + formes de saisie invalide qu'un utilisateur peut entrer. Votre application devrait plutôt utiliser un filtrage positif pour seulement permettre un sous-ensemble spécifique que vous jugez sain. Une mauvaise validation des entrées a été la cause de beaucoup @@ -390,7 +390,7 @@ int main() { aux chemins ("../", "/"), liens symboliques et caractères d'échappement de l'interpréteur de commandes.</para> - <para>Perl possède une caractéristique tès sympathique appelée mode + <para>Perl possède une caractéristique tès sympathique appelée mode "Taint" qui peut être utilisée pour empêcher les scripts d'utiliser des données externes au programme par un moyen non sûr. Ce mode vérifiera les arguments de la ligne de commandes, les variables d'environnement, @@ -405,20 +405,20 @@ int main() { <para>Une condition de course est un comportement anormal causé par une dépendance inattendue sur le séquencement relatif des évènements. En - d'autres mots, un programmeur a supposé à tort qu'un évènement + d'autres mots, un programmeur a supposé à tort qu'un évènement particulier se passerait avant un autre.</para> - <para>Quelques causes habituelles de conditions de course sont les - signaux, les vérifications d'accès et les fichiers ouverts. + <para>Quelques causes habituelles de conditions de course sont les + signaux, les vérifications d'accès et les fichiers ouverts. Les signaux sont des évènements asynchrones par nature aussi un soin particulier doit être pris pour les utiliser. - Vérifier les accès avec <function>access(2)</function> puis + Vérifier les accès avec <function>access(2)</function> puis <function>open(2)</function> n'est clairement pas atomique. Les utilisateurs peuvent déplacer des fichiers entre les deux appels. - Les applications privilégiées devraient plutôt faire un appel à - <function>seteuid()</function> puis appeler <function>open()</function> + Les applications privilégiées devraient plutôt faire un appel à + <function>seteuid()</function> puis appeler <function>open()</function> directement. Dans le même esprit, une application devrait toujours règler - un umask correct avant un appel à <function>open()</function> pour + un umask correct avant un appel à <function>open()</function> pour prévenir le besoin d'appels non valides à <function>chmod()</function>.</para> </sect1> |