OpenBSD - Définition

Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs de cet article est disponible ici.

Le nom

Le nom OpenBSD vient de l'aventure NetBSD de Theo de Raadt. En effet le CVS de NetBSD n'était pas accessible aux non-développeurs officiels ; seules les releases étaient diffusées. Pour son fork, Theo de Raadt a mis en place un serveur CVS public : tout le monde peut accéder aux dernières sources du projet.

La sécurité et l'audit du code

Cette coopération permit également au projet de se concentrer sur un point précis : les développeurs OpenBSD devraient essayer de faire ce qui est correct, propre et sécurisé, même au détriment de la facilité d'utilisation, de la vitesse ou des fonctionnalités. Les failles d'OpenBSD devenant plus difficilement détectables et exploitables, l'entreprise de sécurité statua que l'audit de code était devenu trop difficile et peu rentable. Après des années de coopération, les deux parties s'accordèrent à penser que leurs objectifs communs avaient été atteints et se séparèrent.

L'argument du faible nombre de failles exploitables à distance

Jusqu'en juin 2002, le site web d'OpenBSD affichait le slogan suivant :

« Cinq ans sans vulnérabilité à distance dans l'installation par défaut ! »

En juin 2002, Mark Dow de la société Internet Security Systems découvrit une faille dans le code d'OpenSSH qui implémentait l'authentification par question. Ce fut la première vulnérabilité découverte dans l'installation par défaut d'OpenBSD qui permet à un attaquant d'accéder à distance au compte superutilisateur. L'usage répandu d'OpenSSH à ce moment était à l'origine de la gravité de la faille, qui affectait un nombre considérable d'autres systèmes d'exploitation. Ce problème nécessita l'ajustement du slogan du site web d'OpenBSD :

« Une seule vulnérabilité à distance dans l'installation par défaut, en 6 ans ! »

Cette affirmation a été critiquée du fait du peu de logiciels activés dans l'installation par défaut d'OpenBSD, et du fait également que des failles distantes avaient été découvertes après la publication d'une version. Toutefois, le projet insiste sur le fait que le slogan fait référence à l'installation par défaut, et qu'il est donc correct à ce niveau. Une des idées fondamentales sous-jacentes à OpenBSD est de concevoir un système simple, propre et sécurisé par défaut. Par exemple, les réglages minimaux par défaut correspondent à la pratique standard en sécurité informatique qui consiste à activer aussi peu de services que possible sur les systèmes en production, et le projet pratique des audits de codes considérés comme étant des éléments importants de la sécurité d'un système.

En mars 2007, la découverte d'une nouvelle faille dans OpenBSD, se situant dans la pile IPv6, nécessita le remplacement du slogan par :

« Uniquement deux vulnérabilités à distance dans l'installation par défaut, en plus de 10 ans ! »

À la sortie de la 4.5 le 30 avril 2009, le compte des années est retiré :

« Seulement deux vulnérabilités à distance dans l'installation par défaut, depuis diablement longtemps ! »

Les principales fonctionnalités de sécurité

OpenBSD inclut un grand nombre de fonctionnalités spécifiques destinées à améliorer la sécurité, notamment :

  • des modifications des API et des toolchains, tels que les fonctions strlcpy et strlcat, et une vérification des static bounds ;
  • des techniques de protection de la mémoire pour empêcher les accès invalides, tels que ProPolice, StackGhost, et des fonctionnalités de protection des pages mémoires W^X (W xor X), et des modifications de malloc ;
  • des fonctionnalités de cryptographie et de génération de nombres aléatoires, notamment par des améliorations de la couche réseau et l'ajout de l'algorithme Blowfish pour le chiffrement des mots de passe.

La gestion des privilèges

Pour réduire le risque d'une vulnérabilité ou d'une mauvaise configuration permettant l'usurpation de privilèges, certains programmes ont été écrits ou adaptés pour utiliser la séparation des privilèges, la révocation des privilèges ou la mise en cage (chroot).

La séparation des privilèges est une technique, pionnière sur OpenBSD et inspirée du principe du moindre privilège, dans lequel un programme est divisé en deux ou plusieurs parties, dont l'une effectue les opérations privilégiées, et l'autre — presque toujours le reste du code — fonctionne sans privilège. La révocation des privilèges est similaire et implique qu'un programme réalise toutes les opérations nécessaires avec les privilèges avec lesquels il a été lancé, puis qu'il abandonne ces privilèges. La mise en cage implique de restreindre l'environnement d'exécution d'un programme à une partie du système de fichiers, l'interdisant ainsi d'accéder à des zones qui contiennent des fichiers systèmes ou privés.

Les développeurs ont appliqué ces fonctionnalités aux versions OpenBSD des applications communes, notamment tcpdump et le serveur web Apache, lequel n'est qu'une version 1.3 lourdement modifiée en raison de problèmes de licences avec la série Apache 2.

Audits de code

Le projet suit une politique d'audit permanent du code à la recherche de problèmes de sécurité, un travail que le développeur Marc Espie décrit comme « jamais terminé […] plus une question de processus que de recherche d'un bug spécifique. » Ce dernier a d'ailleurs produit une liste de plusieurs étapes typiques à suivre lorsqu'un bug est détecté, notamment l'examen complet des sources à la recherche de problèmes identiques et similaires, « [en] essayant de déterminer si la documentation nécessite d'être amendée », et en enquêtant pour savoir « s'il est possible d'améliorer le compilateur pour produire des avertissements sur ce problème spécifique. » À l'instar de DragonFly BSD, OpenBSD est l'un des deux systèmes d'exploitation libres dont la politique est de rechercher du code C au format classique pre-ANSI, et de le convertir en son équivalent moderne ANSI. Ceci ne doit pas impliquer des changements de fonctionnalités et n'est réalisé qu'à des fins de lisibilité et de cohérence. Un standard de style, le Kernel Normal Form, qui dicte quelle doit être la forme du code pour faciliter sa maintenance et sa compréhension, doit être appliqué à tout code avant qu'il ne puisse être inclus dans le système d'exploitation de base. Le code existant est sans cesse mis à jour pour correspondre à ces conventions de style.

Page générée en 0.113 seconde(s) - site hébergé chez Contabo
Ce site fait l'objet d'une déclaration à la CNIL sous le numéro de dossier 1037632
A propos - Informations légales
Version anglaise | Version allemande | Version espagnole | Version portugaise