ppt

SEE - Février 2000
Sécurité logique et Objets
Le modèle de sécurité de
Java 2
[email protected]
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
Page 2
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, …
Page 3
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.
Page 4
« 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
Page 5
 contrôle tous les accès aux ressources (en particulier OS)
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 »
Page 6
Modèle de sécurité du JDK 1.0
Page 7
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
Page 8
Modèle de sécurité du JDK 1.1
Page 9
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
Page 10
(implicitement) définir une liste de droits et un système de nommage
des ressources
Le contrôle d’accès (2/5)
Page 11
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 ...
};
grant codebase "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)
Page 12
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);
Page 13
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
Page 14
Modèle de sécurité du JDK 1.2
Signé
ou non
Page 15
Chargeur
de classes
Architecture de sécurité d ’une application Java 1.2
Eléments jouant un rôle dans
la « sandbox »
Chargement des
classes qui ne sont
pas dans le
CLASSPATH
Respect du
langage
Remote class files
Local class files
Signed class files
Byte code verifier
Core API class files
Class loader
Security package
Auth. des
classes
signées
+ crypto.
Page 16
Key database
Core Java API
Limite les
accès
à l ’OS
Security manager
Access controller
Operating system
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
Page 17
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é »
Page 18
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
Page 19
} finally {
AccessController.endPrivileged();
}
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é
Page 20
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
Page 21
Accès aux ressources cryptographiques (3/5)
Page 22
Accès aux ressources cryptographiques (4/5)
Page 23
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
Page 24
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
Page 25
 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
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
Page 26
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, …)
Page 27
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é
Page 28
Exemple de mise en œuvre : Role Based Management
Page 29
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é
Page 30
manques notoires dans la définition des credentials
insuffisances dans l ’expression des identités, des privilèges et
des attributs de sécurité