1 / 30

Le modèle de sécurité de Java 2

SEE - Février 2000 Sécurité logique et Objets. Le modèle de sécurité de Java 2. Laurent.Frerebeau@bull.net. Pourquoi toujours plus de sécurité dans Java ?. Java est un langage particulier : orienté réseau / Internet / Web le code est téléchargé

zan
Télécharger la présentation

Le modèle de sécurité de Java 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SEE - Février 2000Sécurité logique et Objets Le modèle de sécurité de Java 2 Laurent.Frerebeau@bull.net

  2. Pourquoi toujours plus de sécurité dans Java ? • Java est un langage particulier : • orienté réseau / Internet / Web • le code est téléchargé • progressivement (avec possibilité de sources multiples) • dynamiquement (risques de modification) • le vecteur est publique et « à risque » • le code peut avoir besoin d’accéder à des ressources locales • Protéger les ressources locales contre du code ... • malveillant (virus, cheval de Troie, …) • indiscret / instigateur (accès à des informations personnelles) • Protéger le code et les données qu’il gère contre … leurs utilisateurs

  3. De quels services de sécurité a-t-on besoin ? • D’authentification • de l’origine du code • on veut authentifier l’auteur / le fournisseur, pas le colporteur • des utilisateurs du code • D’intégrité • du code transmis • des données générées / manipulées par le code • De confidentialité • des données générées / manipulées par le code • De contrôle d’accès • du code sur les ressources locales • de l’utilisateur sur les ressources locales ou sur les ressources applicatives • D’administration de la sécurité ! • Eventuellement : de non-répudiation, d ’audit, …

  4. Propriétés recherchées • Généricité • Souplesse de configuration et d’utilisation • Interchangeabilité • des moyens cryptographiques • des services de sécurité • authentification • autorisation • administration  Besoin de changer de fournisseur, de s’adapter à des contraintes légales, de suivre l’état de l’Art, etc.

  5. « Sécurité » du langage • Plusieurs niveau d’accès aux classes, méthodes et attributs : • private, package, protected, public • Contrôles d’intégrité à la compilation et à l’exécution • variables non initialisées • dépassement de tableau • conversion de type illégale • Vérificateur de ‘ bytecode ’ (code intermédiaire) • mini-démonstrateur de théorème ; vérifie en particulier : • que le format du fichier est correct • que les classes classes finales ne sont pas sous-classées • que les contraintes générales du langage sont respectées • Chargeur de classe • spécialisable • Gestionnaire de sécurité / Contrôleur d’accès • contrôle tous les accès aux ressources (en particulier OS)

  6. Le « bac à sable » • Ou : « sandbox » • Ce principe existe depuis le JDK 1.0 : • fournir un environnement d’exécution restreint au code « inconnu » (en particulier, celui arrivant du réseau) • limitation des accès • aux ressources locales : • système de fichiers • moyens de communication, sauf vers le serveur ayant transmis le code • à certaines données système • liste des chemins d ’accès aux classes locales • nom de l ’utilisateur courant • ... • Distinction entre « applet » et « application » • une application a « tous les droits » • une applet chargée localement a « tous les droits » • une applet chargée depuis le réseau subit le principe du « bac à sable »

  7. Modèle de sécurité du JDK 1.0

  8. La signature de code • A partir du JDK 1.1, Java permet d’accorder sa confiance à du code téléchargé : • par le biais d’une signature digitale • réalisée au moyen d’outils livrés avec le JDK • la signature associée à une classe (ou un ensemble de classes  fichiers JAR), et les choix de réseaux de confiance exprimés par le réceptionnaire, permettent de garantir à celui-ci l’origine du code téléchargé et son intégrité • le code signé et approuvé obtient les mêmes droits que le code local sur les ressources locales • La distinction entre « applet » et « application » est maintenue en JDK 1.1, mais disparaît en JDK 1.2 : les applications peuvent être soumises à des politiques de sécurité et être signées

  9. Modèle de sécurité du JDK 1.1

  10. Le contrôle d’accès (1/5) • Le JDK 1.2 introduit un modèle de contrôle d’accès fin et paramétrable, applicable aussi bien aux applets qu’aux applications, au travers des notions de : • permission : • un couple droit + ressource • exemple de droit : « read », « write » , « execute », … • exemple de ressource : « fichier », « port », « imprimante », … • les définitions de droit et de ressource sont génériques et extensibles • le modèle est applicable aux ressources applicatives • toutes les classes « permission » doivent : • implémenter une méthode « implies » : • « a implies b » signifie : si la permission « a » est accordée, alors la permission « b » l’est aussi Permission p1 = new FilePermission("/tmp/*", "read"); Permission p2 = new FilePermission("/tmp/readme", "read"); p1.implies(p2) == true p2.implies(p1) == false • (implicitement) définir une liste de droits et un système de nommage des ressources

  11. Le contrôle d’accès (2/5)

  12. Le contrôle d’accès (3/5) • politique de sécurité : • un ensemble de « permissions » • s’applique aussi bien au code local qu’au code réseau • configurée par l’utilisateur ou un administrateur grant [codebase "<URL>"] [signedBy "<alias>"] { permission [permission class] ["target"], ["actions"]; permission ... }; grantcodebase "http://www.sun.com/", signedby "JavaSoft Division" { permission java.net.SocketPermission "java.sun.com", "connect, accept"; }; • les alias font référence à des clés / certificats stockés dans un fichier spécial (‘ keystore ’ maintenu par l’utilisateur)

  13. Le contrôle d’accès (4/5) • origine du code (« code source ») : • un couple auteur + serveur d’origine • domaine de protection • ensemble de classes (désignées par une « origine de code ») dont les instances bénéficient des mêmes « permissions » • une façon de se créer ses propres « bacs à sable »… Permissions permissions = Policy.getPolicy().getPermissions(codesource); ProtectionDomain domain = new ProtectionDomain(codesource, permissions);

  14. Le contrôle d’accès (5/5) • Les applications Java peuvent utiliser ce modèle pour bâtir leur propres contrôles • accès aux options de menus et aux boutons d’action • accès aux données d’une table • ... • Le gestionnaire de sécurité s’appuie sur ce modèle pour contrôler les accès aux ressources locales

  15. Modèle de sécurité du JDK 1.2 Chargeur de classes Signé ou non

  16. Architecture de sécurité d ’une application Java 1.2 Eléments jouant un rôle dans la « sandbox » Remote class files Local class files Respect du langage Chargement des classes qui ne sont pas dans le CLASSPATH Signed class files Byte code verifier Core API class files Class loader Core Java API Security package Limite les accès à l ’OS Auth. des classes signées + crypto. Security manager Key database Access controller Operating system

  17. Le chargeur de classes • Un des rôles fondamentaux d’un chargeur de classe est de maintenir une distinction de nommage entre des classes chargées sur des sites différents : • deux classes de même nom (et éventuellement de même package), chargée depuis deux sites différents ne sont pas équivalentes et peuvent avoir des permissions différentes • le JDK 1.2 facilite le développement de nouveau chargeurs de classe • Le JDK 1.2 est livré avec deux nouveaux chargeurs : • le ‘ SecureClassLoader ’ : • sert de base au développement d’autres chargeurs de classe • associe un domaine de protection aux classes qu’il charge • l ’ ‘ URLClassLoader ’ : • chargeur à usage général

  18. Gestionnaire de sécurité et contrôleur d’accès • Ou : « Security Manager » et « Access Controller » • Le gestionnaire de sécurité existe depuis le JDK 1.0 mais été remanié en 1.2 : • est maintenu en 1.2 pour des raisons de compatibilité • sous-traite toutes les tâches de calcul de contrôle d ’accès au contrôleur d ’accès • Le contrôleur d’accès est un nouveau composant en 1.2 : • réalise toute les prises de décision d’accès « système », sur la base de fichiers de politique de sécurité • est impliqué dans le passage de morceaux de code en mode « privilégié »

  19. Blocs et objets protégés • Très utile pour les composants intermédiaires d’architectures trois tiers, ou les composants qui font de la délégation de service (serveur d ’imprimante, par exemple), etc. • Permet à un composant d’exécuter un bout de code avec ses permissions propres (ie. : celles liées à l’origine et au signataire du composant), indépendamment de celles de celui qui a appelé le composant exécutant la fonction protégée void someMethod() { // normal code here try { AccessController.beginPrivileged(); // privileged code goes here } finally { AccessController.endPrivileged(); }

  20. Accès aux ressources cryptographiques (1/5) • JCA : Java Cryptography Architecture • introduit avec le JDK 1.1 • concentre les accès aux ressources cryptographiques • modèle à « fournisseur de services » • deux niveaux d ’API : • les classes « moteur » : API présentant sous forme générique des services cryptographiques de base à du code client • l’interface « SPI » : permet à un fournisseur d’implémentation de service cryptographique de s’insérer dans l ’infrastructure • des CSP : « Cryptographic Service Provider » • le JDK 1.1 fournit des services • de calcul de condensats • de signature / vérification de signature de message • le JDK 1.2 en ajoute quelques autres : • création et gestion d ’espace de stockage de clés et de certificats • gestion des paramètres liés aux algorithmes • ‘ Key Factory ’ : conversion de formats de clé

  21. Accès aux ressources cryptographiques (2/5) • ‘ Certificate Factory ’ : génération de certificats et de CRL et support de plusieurs encodages • fourniture d’un service (surchargeable) de génération de nombres aléatoires • la JRE 5.2 arrive avec une implémentation minimale (Sun) • DSA, MD5, SHA-1, géné. certif. et CRL, KeyStore, géné. aléa. • A cela s’ajoute un package supplémentaire : JCE (Java Cryptographic Extensions) • diffusion restreinte • échanges de clés • chiffrement / déchiffrement • calculs de MAC (Message Authentication code) • implémentation Sun : DES, 3DES, PBE, DH, HMAC... • Remarques : • les possibilités de signature et de vérification de signature de classe, y compris pour le code chargé localement, prennent alors toute leur importance

  22. Accès aux ressources cryptographiques (3/5)

  23. Accès aux ressources cryptographiques (4/5)

  24. Accès aux ressources cryptographiques (5/5) • Autres nouveautés : • classes de manipulation de certificat • décodage et gestion de certificats • support de X509 V3 • mais ouvert à d ’autres formats et à d’autres encodages • classes de manipulation de clés et de paires de clés • classe ‘ engine ’ « KeyStore » + 1 fournisseur par défaut • des interfaces de spécification de clé, permettant de manipuler des clés indépendamment de leur représentation

  25. JAAS (1/3) • « Java Authentication and Authorization Service » • Extension à la plate-forme Java • Part d’une remarque : • le contrôleur d’accès s’intéresse à l’origine du code et à qui l’a signé • JAAS s ’intéresse à qui exécute ou fait exécuter le code • JAAS adresse les besoins des applications qui veulent s’adapter à leurs utilisateurs en les authentifiant, en contrôlant leurs caractéristiques avant de leur imposer des contrôles d’accès • Inclut deux composants • un composant d’authentification des utilisateurs • un composant d’autorisation qui travaille à la manière du contrôleur d’accès avec en plus des informations utilisateur

  26. JAAS (2/3) • S’inspire des principes et de l’architecture de la technologie PAM (Pluggable Authentication Module) de Sun • Prévoit le support de modèles de contrôle d’accès orientés utilisateur, groupes d’utilisateurs ou privilèges • dans les faits, ne supporte que le contrôle d’accès basé sur le nom de principal • Principe d’extensions / remplaçabilité par des plug-ins

  27. JAAS (3/3) • Introduit les notions de : • sujet : • entité qui peut être authentifiée • identité • « nom » utilisé pour l’authentification • principal : • entité authentifiée à un moment donné • « credential » : • données ou preuves d’authentication • domaine de technologie de sécurité : • environnement regroupant les composant utilisant un même mécanisme de sécurité (Kerberos, DCE, …)

  28. Les outils • Les nouveaux : • keytool : • permet de gérer les clés et les certificats permettant de signer des applications et des applets • met à jour une base de données appelée ‘ keystore ’ • jarsigner : • signe et vérifie la signature de JAR • s’appuie sur le ‘ keystore ’ • policytool : • crée et modifie des fichiers de politiques de sécurité

  29. Exemple de mise en œuvre : Role Based Management

  30. Conclusion • Le JDK 1.2 dispose de tout ce qu’il faut pour concevoir désormais des applications sécurisées réellement sécurisées • Les bons points : • JCA • le modèle à base de permissions • simple et de bon goût • Les déceptions : • la disponibilité de JCE ou d’équivalents bon marché • un package JAAS prometteur mais non finalisé • manques notoires dans la définition des credentials • insuffisances dans l ’expression des identités, des privilèges et des attributs de sécurité

More Related