L'architecture de sécurité de Java

La chronique "Under The Hood" de ce mois-ci est la première d'une série en quatre parties sur le modèle de sécurité de Java. Les quatre articles se concentreront sur l'infrastructure de sécurité intégrée à la machine virtuelle Java (JVM) et à la bibliothèque java.lang. Ce premier article donne un aperçu du modèle de sécurité et décrit les fonctionnalités de sécurité de la JVM.

Pourquoi la sécurité?

Le modèle de sécurité de Java est l'une des principales caractéristiques architecturales du langage qui en fait une technologie appropriée pour les environnements en réseau. La sécurité est importante car les réseaux offrent une possibilité d'attaque contre tout ordinateur qui y est connecté. Cette préoccupation devient particulièrement forte dans un environnement dans lequel le logiciel est téléchargé sur le réseau et exécuté localement, comme c'est le cas avec les applets Java, par exemple. Étant donné que les fichiers de classe d'une applet sont automatiquement téléchargés lorsqu'un utilisateur accède à la page Web contenant dans un navigateur, il est probable qu'un utilisateur rencontre des applets provenant de sources non approuvées. Sans aucune sécurité, ce serait un moyen pratique de propager des virus. Ainsi, les mécanismes de sécurité de Java contribuent à rendre Java adapté aux réseaux car ils établissent une confiance nécessaire dans la sécurité du code réseau-mobile.

Le modèle de sécurité de Java est axé sur la protection des utilisateurs contre les programmes hostiles téléchargés à partir de sources non fiables sur un réseau. Pour atteindre cet objectif, Java fournit un «bac à sable» personnalisable dans lequel les programmes Java s'exécutent. Un programme Java ne doit jouer que dans son bac à sable. Il peut tout faire dans les limites de son bac à sable, mais il ne peut entreprendre aucune action en dehors de ces limites. Le bac à sable pour les applets Java non approuvées, par exemple, interdit de nombreuses activités, notamment:

  • Lecture ou écriture sur le disque local
  • Établissement d'une connexion réseau à n'importe quel hôte, à l'exception de l'hôte d'où provient l'applet
  • Créer un nouveau processus
  • Chargement d'une nouvelle bibliothèque dynamique et appel direct d'une méthode native

En empêchant le code téléchargé d'effectuer certaines actions, le modèle de sécurité de Java protège l'utilisateur contre la menace d'un code hostile.

Le bac à sable défini

Traditionnellement, vous deviez faire confiance aux logiciels avant de les exécuter. Vous avez atteint la sécurité en veillant à n'utiliser que des logiciels provenant de sources fiables et en recherchant régulièrement des virus pour vous assurer que tout était en sécurité. Une fois qu'un logiciel a eu accès à votre système, il a eu la pleine maîtrise. S'il était malveillant, cela pourrait causer de gros dommages à votre système car il n'y avait aucune restriction imposée au logiciel par l'environnement d'exécution de votre ordinateur. Ainsi, dans le schéma de sécurité traditionnel, vous avez essayé d'empêcher un code malveillant d'accéder à votre ordinateur en premier lieu.

Le modèle de sécurité sandbox facilite le travail avec des logiciels provenant de sources auxquelles vous ne faites pas entièrement confiance. Au lieu d'établir la sécurité en vous obligeant à empêcher tout code auquel vous ne faites pas confiance de pénétrer sur votre ordinateur, le modèle sandbox vous permet d'accueillir le code de n'importe quelle source. Mais pendant son exécution, le bac à sable empêche le code provenant de sources non fiables de prendre des mesures qui pourraient éventuellement nuire à votre système. L'avantage est que vous n'avez pas besoin de déterminer à quel code vous pouvez et ne pouvez pas faire confiance, et vous n'avez pas besoin de rechercher des virus. Le bac à sable lui-même empêche tout virus ou autre code malveillant que vous pourriez inviter dans votre ordinateur de causer des dommages.

Le bac à sable est omniprésent

Si vous avez un esprit sceptique, vous devez être convaincu qu'un bac à sable ne présente aucune fuite avant de lui faire confiance pour vous protéger. Pour s'assurer que le bac à sable ne présente aucune fuite, le modèle de sécurité de Java implique tous les aspects de son architecture. S'il y avait des zones de l'architecture Java dans lesquelles la sécurité était faible, un programmeur malveillant (un "cracker") pourrait potentiellement exploiter ces zones pour "contourner" le bac à sable. Pour comprendre le bac à sable, par conséquent, vous devez examiner plusieurs parties différentes de l'architecture de Java et comprendre comment elles fonctionnent ensemble.

Les composants fondamentaux responsables du sandbox de Java sont:

  • Fonctions de sécurité intégrées à la machine virtuelle Java (et au langage)
  • L'architecture du chargeur de classe
  • Le vérificateur de fichiers de classe
  • Le gestionnaire de sécurité et l'API Java