doc/fr_FR.ISO8859-1/htdocs/security/security.xml
Gabor Kovesdan 77d737ee88 - Rename the share/sgml directories to share/xml
- Fix build errors from the next change

Approved by:	doceng (implicit)
2012-10-01 11:56:00 +00:00

430 lines
15 KiB
XML

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/xml/xhtml10-freebsd.dtd" [
<!ENTITY title "Informations sur la sécurité sous FreeBSD">
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
]>
<!-- $FreeBSD$ -->
<!--
The FreeBSD French Documentation Project
Original revision: 1.185
Version francaise : Guillain
Relecture : Thomas Seyrat
Version francaise (mise a jour) : Stephane Legrand <stephane@freebsd-fr.org>
-->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.support">
<h2>Introduction</h2>
<p>Cette page web a été conçue afin
d'accompagner les utilisateurs, nouveaux venus ou
expérimentés, dans le domaine de la
sécurité de FreeBSD. FreeBSD prend la
sécurité très au sérieux et travaille
sans cesse pour rendre le système d'exploitation aussi
sûr que possible.</p>
<p>Vous trouverez ici des informations complémentaires, ou
des liens vers d'autres ressources, qui vous aideront &agrave;
protéger votre système contre différents
types d'attaques, sur qui contacter si vous trouvez une
éventuelle faille, etc. Les programmeurs systèmes
seront heureux de trouver une section traitant des techniques
&agrave; employer pour éviter avant toute chose de
créer soi-même des failles.</p>
<h2>Table des Matières</h2>
<ul>
<li><a href="#how">Comment et où rapporter un
problème de sécurité dans FreeBSD</a></li>
<li><a href="#sec">Informations sur l'officier de
sécurité FreeBSD</a></li>
<li><a href="&enbase;/security/charter.html">Charte de l'officier
de sécurité et de son équipe</a></li>
<li><a href="#pol">Politique de gestion de l'information</a></li>
<li><a href="#adv">Avis de sécurité FreeBSD</a></li>
<li><a
href="&enbase;/doc/&url.doc.langcode;/books/handbook/security-advisories.html">Lire
les avis de sécurité FreeBSD</a></li>
</ul>
<a name="how"></a>
<p>Tout problème de sécurité FreeBSD doit
être rapporté &agrave; <a
href="mailto:secteam@FreeBSD.org">l'équipe de
sécurité FreeBSD</a> ou, si plus de
confidentialité est nécessaire, &agrave; <a
href="mailto:security-officer@FreeBSD.org">l'équipe de
l'officier de sécurité</a>. Chaque rapport devrait
contenir au moins:</p>
<ul>
<li>Une description de la vulnérabilité;</li>
<li>Quelles version de FreeBSD semblent affectées si
possible;</li>
<li>Toute solution potentielle;</li>
<li>Un exemple de code si possible.</li>
</ul>
<p>Après que cette information ait été
rapportée, l'officier de sécurité ou un
membre de l'équipe de sécurité reviendra
&agrave; vous.</p>
<a name="sec"></a>
<h2>L'officier de sécurité FreeBSD et l'equipe de
l'officier de Sécurité</h2>
<p>Pour mieux coordonner les échanges avec d'autres personnes
dans la communauté de la sécurité, FreeBSD a
une personne centrale pour toute communication liée
&agrave; la sécurité: l'officier de
sécurité FreeBSD.</p>
<p>Si vous voulez contacter le projet FreeBSD &agrave; propos d'un
problème de sécurité possible, vous devez
donc <a href="mailto:security-officer@FreeBSD.org">envoyez un
courrier électronique &agrave; l'officier de
sécurité</a> avec une description de ce que vous
avez trouvé et le type de vulnérabilité qu'il
présente.</p>
<p>Pour que le projet FreeBSD réponde plus rapidement aux
rapports de vulnérabilité, il y a quatre membres
derrière l'alias courrier électronique de l'officier
de sécurité: l'officier de sécurité,
l'officier de sécurité émérite,
l'officier de sécurité adjoint, et un membre de
l'équipe de base. En conséquence, les messages
envoyés &agrave; <a
href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
seront transmis &agrave;:</p>
<table>
<tr valign="top">
<td>&a.cperciva; <a
href="mailto:cperciva@FreeBSD.org">&lt;cperciva@FreeBSD.org&gt;</a></td>
<td>Officier de sécurité</td>
</tr>
<tr valign="top">
<td>&a.nectar; <a
href="mailto:nectar@FreeBSD.org">&lt;nectar@FreeBSD.org&gt;</a></td>
<td>Officier de sécurité émérite</td>
</tr>
<tr valign="top">
<td>&a.simon; <a
href="mailto:simon@FreeBSD.org">&lt;simon@FreeBSD.org&gt;</a></td>
<td>Officier de sécurité adjoint</td>
</tr>
<tr valign="top">
<td>&a.rwatson; <a
href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
<td>Liaison avec l'équipe de base FreeBSD, liaison avec
l'équipe chargée des versions,<br/>
liaison avec le projet TrustedBSD, expert en architecture de
la sécurité système</td>
</tr>
</table>
<p>L'Officier de sécurité est supporté par <a
href="&enbase;/doc/en_US.ISO8859-1/articles/contributors/staff-listing.html#STAFF-SECTEAM">l'équipe
de sécurité FreeBSD</a> <a
href="mailto:secteam@FreeBSD.org">&lt;secteam@FreeBSD.org&gt;</a>,
un petit groupe de participants contrôlé par
l'officier de sécurité.</p>
<p>Veuillez utiliser la <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">clé
PGP de l'officier de sécurité</a> pour chiffrer vos
messages &agrave; l'officier de sécurité si
approprié.</p>
<a name="pol"></a>
<h2>Politiques de gestion de l'information</h2>
<p>En général, l'officier de sécurité
FreeBSD privilégie la transparence totale sur les
vulnérabilités après un delai raisonnable
pour permettre d'analyser et de corriger une
vulnérabilité, ainsi que de tester de manière
appropriée ce correctif, et de se coordonner avec les
autres parties affectées.</p>
<p>L'officier de sécurité <em>informera</em> un ou
plusieurs <a href="mailto:admins@FreeBSD.org">administrateurs du
cluster FreeBSD</a> de vulnérabilités mettant les
ressources du projet FreeBSD en danger immédiat.</p>
<p>L'officier de sécurité peut contacter d'autres
développeurs FreeBSD ou des développeurs
extérieurs &agrave; propos d'une
vulnérabilité si leur expertise est
nécessaire pour comprendre ou corriger le problème.
Une discrétion appropriée permettra de minimiser la
fuite d'information non nécessaire sur la
vulnérabilité soumise, et tout expert
contacté devra suivre la politique de l'officier de
sécurité. Dans le passé, des experts ont
été contactés &agrave; cause de leur
expérience importante sur des composants complexes du
système d'exploitation, comme FFS, la mémoire
virtuelle, et la pile réseau.</p>
<p>Si une nouvelle version de FreeBSD est en préparation, le
responsable de la sortie de nouvelles versions peut être
informé que la vulnérabilité existe, et de sa
sévérité, pour que des décisions
soient prises sur le cycle de sortie des versions et sur les
bogues présents dans une version sur le point de sortir.
Si ceci est demandé, l'officier de sécurité
ne partagera pas la nature exacte de la
vulnérabilité avec le responsable de la sortie de
nouvelles versions, limitant ainsi les informations &agrave;
l'existence et la sévérité.</p>
<p>L'officier de sécurité travaille étroitement
avec de nombreuses autres organisations, comme des vendeurs
partageant du code avec FreeBSD (les projets OpenBSD, NetBSD et
DragonFlyBSD, Apple, et d'autres vendeurs utilisant des logiciels
de FreeBSD, ainsi que la liste sécurité des vendeurs
Linux), ainsi que des organisations recensant les
vulnérabilités et les incidents de
sécurité comme le CERT. Souvent, les
vulnérabilités s'étendent au del&agrave; de
l'implémentation de FreeBSD, et (moins fréquemment)
ont de larges implications sur la communauté du
réseau global. Dans de telles circonstances, l'officier de
sécurité peut souhaiter divulguer cette information
&agrave; ces autres organisations : si vous ne voulez pas que
l'officier de sécurité fasse ceci, veuillez
l'indiquer explicitement dans votre soumission.</p>
<p>La personne soumettant une vulnérabilité doit
veiller &agrave; mentionner explicitement toute gestion
spéciale de l'information.</p>
<p>Si la personne soumettant une vulnérabilité est
interessée par une divulgation coordonnée avec elle
et/ou d'autres vendeurs, ceci doit être indiqué
explicitement dans la soumission. En l'absence de demande
explicite, l'officier de sécurité FreeBSD choisira
un calendrier de divulgation qui reflète &agrave; la fois
une divulgation rapide et des tests appropriés de toute
solution. Il faut savoir que si la vulnérabilité
est révélée sur des forums publics (comme
bugtraq), et qu'elle est exploitée, l'officier de
sécurité peut choisir de ne pas suivre le calendrier
proposé pour protéger au maximum la
communauté des utilisateurs.</p>
<p>Les soumissions peuvent être protégées avec
PGP. Si ceci est désiré, les réponses seront
également protégées avec PGP.</p>
<a name="adv"></a>
<h2>Avis de sécurité FreeBSD</h2>
<p>L'officier de sécurité FreeBSD publie des avis de
sécurité pour différentes branches de
FreeBSD. Celles-ci sont les <em>branches -STABLES</em> et les
<em>branches de sécurité</em>. (les avis ne sont pas
publiés pour la <em>branche -CURRENT</em>.)</p>
<ul>
<li><p>Il n'y a en général qu'une branche -STABLE,
bien que durant la transition d'une ligne de
développement &agrave; une autre (comme de FreeBSD 4.X
&agrave; 5.X), il y a une période durant laquelle il y a
2 branches -STABLE. Les étiquettes des branches stables
ont des noms comme <tt>RELENG_4</tt>. Les compilations
correspondantes ont des noms comme <tt>FreeBSD
4.10-STABLE</tt>.</p></li>
<li><p>Chaque version de FreeBSD a une branche de
sécurité associée. Les étiquettes
des branches de sécurité ont des noms comme
<tt>RELENG_4_10</tt>. Les compilations correspondantes ont des
noms comme <tt>FreeBSD 4.10-RELEASE-p5</tt>.</p></li>
</ul>
<p>Les problèmes touchant le catalogue des logiciels
portés FreeBSD sont couverts dans <a
href="http://vuxml.FreeBSD.org/">le document FreeBSD
VuXML</a>.</p>
<p>Chaque branche est supportée par l'officier de
sécurité pour une durée limitée, et a
un type parmi `<em>Premiers Utilisateurs</em>',
`<em>Normale</em>', ou `<em>Etendue</em>'. Ce type est
utilisé pour déterminer la durée de vie de la
branche comme suit.</p>
<dl>
<dt>Premiers utilisateurs</dt>
<dd>Les versions publiées &agrave; partir de la branche
-CURRENT seront supportées un minimum de 6 mois
après leur sortie.</dd>
<dt>Normale</dt>
<dd>Les versions publiées &agrave; partir de la branche
-STABLE seront supportées par l'officier de
sécurité durant un minimum de 12 mois après
leur sortie.</dd>
<dt>Etendue</dt>
<dd>Des versions choisies seront supportées par l'officier
de sécurité durant un minimum de 24 mois aprè
leur sortie.</dd>
</dl>
<a name="supported-branches"></a>
<p>Le type et la durée de vie estimée des branches
actuellement supportées sont données ci-dessous. La
colonne <em>Fin de vie estimée</em> donne la date minimale
lors de laquelle cette branche ne sera plus supportée.
Veuillez noter que ces dates peuvent être étendues
dans le futur, mais que seules des circonstances exeptionnelles
feraient que le support soit arrêté plus tôt
que la date prévue.</p>
<!--
Please also update www/en/releng/index.xml when updating this
list of supported branches.
-->
<table class="tblbasic">
<tr>
<th>Branche</th>
<th>Version</th>
<th>Type</th>
<th>Date de Sortie</th>
<th>Fin de vie estimée</th>
</tr>
<tr>
<td>RELENG_4</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>31 Janvier 2007</td>
</tr>
<tr>
<td>RELENG_4_10</td>
<td>4.10-RELEASE</td>
<td>Etendue</td>
<td>27 Mai 2004</td>
<td>31 Mai 2006</td>
</tr>
<tr>
<td>RELENG_4_11</td>
<td>4.11-RELEASE</td>
<td>Etendue</td>
<td>25 Janvier 2005</td>
<td>31 Janvier 2007</td>
</tr>
<tr>
<td>RELENG_5</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>31 Mai 2008</td>
</tr>
<tr>
<td>RELENG_5_3</td>
<td>5.3-RELEASE</td>
<td>Etendue</td>
<td>6 Novembre 2004</td>
<td>31 Octobre 2006</td>
</tr>
<tr>
<td>RELENG_5_4</td>
<td>5.4-RELEASE</td>
<td>Normale</td>
<td>9 Mai 2005</td>
<td>31 Octobre 2006</td>
</tr>
<tr>
<td>RELENG_5_5</td>
<td>5.5-RELEASE</td>
<td>Etendue</td>
<td>25 Mai 2006</td>
<td>31 Mai 2008</td>
</tr>
<tr>
<td>RELENG_6</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td>31 Mai 2008</td>
</tr>
<tr>
<td>RELENG_6_0</td>
<td>6.0-RELEASE</td>
<td>Normale</td>
<td>4 Novembre 2005</td>
<td>30 Novembre 2006</td>
</tr>
<tr>
<td>RELENG_6_1</td>
<td>6.1-RELEASE</td>
<td>Etendue</td>
<td>9 Mai 2006</td>
<td>31 Mai 2008</td>
</tr>
</table>
<p>Les versions plus anciennes ne sont plus maintenues et les
utilisateurs sont vivement incités &agrave; mettre leur
système &agrave; jour vers une branche mentionnée
ci-dessus.</p>
<p>Quelques statistiques sur les avis de sécurité
émis en 2002:</p>
<ul>
<li>44 avis de différentes sévérités
ont été émis pour le système de
base.</li>
<li>12 avis ont décrit des vulnérabilités
concernant uniquement FreeBSD. Les 32 restants étaient des
problèmes qui concernaient au moins un autre système
d'exploitation (souvent parce que le code source était
commun).</li>
<li>6 notices de sécurité ont été
publiées, couvrant un total de 95 problèmes dans les
applications tierces inclues dans le catalogue des logiciels
portés.</li>
</ul>
<p>Les avis sont envoyés aux listes de diffusion FreeBSD
suivantes:</p>
<ul>
<li>FreeBSD-security-notifications@FreeBSD.org</li>
<li>FreeBSD-security@FreeBSD.org</li>
<li>FreeBSD-announce@FreeBSD.org</li>
</ul>
<p>Les avis sont toujours signés avec la <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">clé
PGP</a> de l'officier de sécurité FreeBSD et sont
archivés, aux côtés de leurs correctifs, sur
notre <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/index.html">dépôt
FTP CERT</a>. A ce jour, les avis suivants sont disponibles
(notez que cette liste a peut-être quelques jours de retard
- pour les tout derniers avis, veuillez consulter le <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/">site
FTP</a>):</p>
&advisories.html.inc;
</body>
</html>