Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Jan Steinmann Geändert vor über 9 Jahren
1
Folie: 1 JAVA Sicherheit TM Vortragender: Daniel Nowak
2
Übersicht Das Basis-Sicherheitskonzept der Java Virtual Machine Sandbox Der Class Loader Der Class File Verifier Der Security Manager Neue Sicherheitsmechanismen in Java 2 Sicherheitsstrategien( Policy) policytool Zugriffskontrolle – Stack Inspection Objekte des neuen Sicherheitskonzeptes Identity Permission Access Contoller Protection Domain Policy Cryptografie Folie: 2
3
Motivation höchst populäre Entwicklungsplattform mobiler Code -dynamischer Download Komponenten-basiert... wichtig für e-Commerce Millionen Internetnutzer (Netscape Navigator, Internet Explorer) Browser bringen ihre eigene VM mit Javas Portabilität erlaubt es, Applets an Webpages anzuhängen...und Entwickler von Java-Programmen Java bietet viel bezüglich Sicherheit: Crypto APIs Sicherheitsmechanismen in der Sprache/Architektur schwierig, unsicheren Code zu schreiben...das heißt aber nicht, sichere Programmentwicklung in Java ist trivial Folie: 3
4
Gefahrenquelle: ausführbarer Code 4 Klassen von Sicherheitsangriffen: Java dämmt diese Gefahr ein durch: JVM lässt den Code nur in abgesichertem Bereich laufen („Sandbox“) strikte Zugriffskontrolle auf das umgebene System Bytecode wahrt das Sandbox-Prinzip Programmiersprache Folie: 4
5
Java als Sprache Java als Sprache scheint wichtig zu sein: keine Pointer-Arithmetik keine ungültigen Speicherzugriffe Garbage Collection automatisches Prüfen von Arraylängen strenge Typisierung keine illegalen Casts, Objektzugriffe Zugriffsrechte Einschränkung der Sichtbarkeit von Elementen Exception Handling Objektorientierung(Data-Hiding, Abstaktion,Kapselung) Sicherheitsdesign Aber wichtiger ist die zugrunde liegende JVM ! Portabilität Bytecode Java Source Code Bytecode Folie: 5 durch
6
Das Basis-Sicherheitskonzept der JVM Konzept der sicheren Sandbox für Java-Programme Die Sandbox wird durch 3 eng zusammenwirkende Teile realisiert: – Class Loader separiert geladene von lokalen Klassen – Class File Verifier Verifikation aller Klassen, die in die Sandbox geladen werden v.a. Gewährleistung der Typsicherheit – Security Manager überprüft (Datei-,...)Zugriffsversuche außerhalb der Sandbox zur Laufzeit Folie: 6
7
Die Sandbox-Restriktionen Was soll verhindert werden? – Veränderungen am Browsersystem(z.B. durch Systemaufrufe, Dateiupdates) – lokaler Speicherzugriff: unerlaubtes Lesen/Schreiben von Dateien,Umgebungsvariablen Löschen, Anlegen von Dateien/Verzeichnissen Auslesen von Verzeichnissen – Aufbau von Netzwerkverbindungen(„phone home“-Regel) – Portlistening – System-Properties auslesen/setzen (user.name...) – willkürliche Programmausführung(Runtime.exec()) – Terminierung des Java Interpreters – Dynamisches Laden von Libraries – Manipulation von Threads – Installieren eigener Class Loader, Security Manager – Überschreiben oder Korruption von System-Klassen Folie: 7
8
Der Class Loader...ist dafür verantwortlich, alle verschiedenen Teile eines Programmes zusammenzubringen, damit es ausführbar ist. Folie: 8 JVM Bytecode Internet Class Loader
9
Der Class Loader Aufgaben: – Laden,Trennen und Verwalten von Klassen Einteilung in sicher/unsicher – Schutz der Java System-Klassen Anmerkungen: o Verhindern von Überschreibung vertrauenswürdiger JVM-Klassen durch gleichnamige Klassen von einem Webserver o Erzeugung konkreter Klassen erst nach dem Verifikationsprozess o Zugriffsrechte auf Elemente innerhalb der Systemklassen-Packages ( java.* ) müssen geschützt werden(Sichtbarkeitsbeschränkungen) Eigene Klassen dürfen deshalb nicht diesen Packages hinzugefügt werden. Folie: 9
10
Class Loader Implementierungen 1 eingebauter Class Loader (Primordial Class Loader), der für das Laden der System-Klassen verantwortlich ist meist in C geschrieben volle Rechtevergabe an geladene Klassen es kann bel. viele zusätzliche Class Loader geben für Web-Browser z.B. gibt es den Applet Class Loader für jeden zusätzlichen ClassLoader kann es mehrere Instanzen geben – eine pro Codebase damit: » eigene Namespaces » keine Namenskollisionen » keine Sichtbarkeit zwischen Namespaces Folie: 10
11
Class Loader Hierarchie Bei der Suche nach Klassen wird eine Class Loader-Hierarchie durchlaufen: direkte Kommunikation zwischen Class Loadern Suchreihenfolge: System-Klassen lokale Klassen Remote-Klassen Abgeleitete Class Loader (Java2) : Folie: 11 Primordial Class Loader java.lang.ClassLoader java.security.SecureClassLoader java.net.URLClassLoader AppletClassLoader Applikation Applet System-Klassen
12
Class Loader Interaktion Ablauf für das Laden einer Klasse über das Netz: 1 verantwortlicher AppletClassLoader wird kontaktiert 2 lokaler Cache des AppletClassLoaders wird durchsucht 3 Anfrage an Primordial ClassLoader 4 Laden der Klasse vom Host Folie: 12
13
Der Class File Verifier...prüft, ob das Programm nach den Regeln der JVM läuft das bedeutet nicht unbedingt, dass das Programm die Regeln von Java als Sprache befolgt Folie: 13 JVM Bytecode Regeln Class File Verifier Internet Class Class Loader
14
Java Bytecode...ist die Maschinensprache der JVM. Beibehaltung des oo-Konzepts Sicherheitstechnische Aspekte für die Verifikation von Bytecode: korrupter Java Cross-Compiler generiert Bytecode aus unsicherer Sprache (Cobol,Delphie) Umgehung des Java Sicherheitskonzepts Folie: 14
15
Aktivierung des Class File Verifier Wann wird der Class File Verifier benötigt? Folie: 15 JVM initiiert das Laden von Klassen PrimordialClass Loader für System- Klassen Applet Class Loader holt Klassen über das Netz Class File Verifier In Java 2 auch Applikationen (URLClassLoader)
16
Bytecode-Verifikation Die 4 Phasen der Verifikation: – Datei-Integrität überprüfen Format(0xCAFEBABE),Länge – Klassen-Integrität überprüfen Superklasse(wenn vorhanden) nicht final Name und Signatur von Methoden und referenzierten Klassen – Bytecode-Integrität überprüfen Datenfluß-Analyse Stack-Checking statische Typüberprüfung – Laufzeit-Integrität überprüfen dynamische Typüberprüfungen Folie: 16 ExeptionsExeptions
17
Security Manager JVM Der Security Manager Folie: 17 mobiler Code OS-Calls ja nein Exception Der Security Manager überwacht potentiell gefährliche Operationen auf dem OS.
18
Der Security Manager Ursprüngliches Konzept in Java 1.1: definiert check-Methoden, die kritische Aktionen überwachen - z.B. checkRead, checkAccess, checkExit, checkConnect - insg. 29 Methoden Applikationen bringen meist eigene Implementierung des Security Manager mit. - fein-körnige Kontrolle möglich, aber umständlich (besser:Java2) Für Applets gilt der Security Manager des Browsers. -...ist für die Sandbox-Restriktionen verantwortlich Jede laufende JVM hat max. 1 Security Manager! - kann nicht ausgetauscht werden! enge Kooperation zwischen Security Manager und Class Loader Folie: 18
19
Erweiterung des Sicherheitsmodells zu klärende Anforderungen: – WOHER kommt der Java-Code bzw. WEM kann ich trauen? – Signaturen, Zertifikate – WAS darf das Programm tun? – Permissions (bzw.Rechte) – WIE kann ich die Vertraulichkeit der Daten sichern, die mein Applet verarbeitet? Die Antwort hierauf ist Cryptographie....in Java gibt es hierzu die APIs JCA und JCE. Folie: 19
20
Sicherheit auf API-Level Java Cryptographie Architecture (JCA 1.2) -- im JDK enthalten besteht aus 5 Packages: – java.security – java.security.acl – java.security.interfaces – java.security.spec – java.security.cert Java Cryptographie Extension (JCE) -- nur für US und Canada java.crypto.* - Standardisierung von sicheren Streams, Key-Generatoren, Cipher Support Folie: 20
21
Java Cryptographie Architecture flexibles Framework: Verschiedene Provider können ihre eigenen Implementationen der Cryptographie-Tools und anderer administrativer Funktionen anbieten. Folie: 21 Provider 3 Algorithmus A Algorithmus B Algorithmus C Provider 2 Algorithmus A Algorithmus B Algorithmus C Provider 1 Algorithmus A Algorithmus B Algorithmus C Engine Classes Signature KeyPair MessageDigest etc... User Code
22
Rechtevergabe Frage: Was darf ein fremdes Programm auf meinem System tun? 2 Ansätze: – JDK1.1 Schwarz-Weiß-Prinzip (Sandbox) vertrauenswürdig -- nicht vertrauenswürdig – Java 2 Graustufen-Prinzip dosierbare Vergabe von Rechten flexibel z.B. Satz von Rechten für Videokonferenz-Applets Folie: 22
23
Java 2 Grundidee: Jeder Code läuft unter einer Sicherheitspolitik, welche Programmen verschiedene Rechte zuordnet! wichtiger Punkt in Java 2-Sicherheitsmodell: Code-Signatur Signaturen allein lassen aber keine graduelle Entscheidungen über Rechtevergabe für Programme zu. 4 zentrale Capabilities: fein dosierte Zugriffskontrolle konfigurierbare Sicherheitspolitik erweiterbare Zugriffskontrollstruktur Sicherheitsprüfung für alle Programme Folie: 23 Zugriffskontroll- mechanismen
24
Java 2 Sicherheitskonzept Folie: 24 Code Source Signers Bytecode Identity Java Runtime Policy Access Controller " Stack Inspection Grundstein für Java2 Sicherheit: policy (java.security.Policy) Ausführbarer Code wird durch seine Herkunfts-URL und Signatur kategorisiert. Solchen (URL,Signatur)-Paaren werden dann Zugriffsrechte zugeordnet
25
Sicherheitselemente- Identity+Permission Folie: 25 Version von SUN: – Identity » Basis für sicherheitskritische Entscheidungen – Permission » Kapselung sicherheitskritischer Anfragen(System-Calls) » abstrakt: java.security.Permission Herkunft Signatur java.security.CodeSource URL public key FilePermission SocketPermission PropertyPermission RuntimePermission NetPermission AWTPermission target action java.security.Permission eigene Permissions
26
Sicherheitselemente - Policy Folie: 26 – Policy » Zuordnung von Identity und Permissions zu Code (Matrix) (ähnlich dem Security Manager) » Benutzerdefiniert policytoolpolicytool grant CodeBase „http://www.example.com/users/dummy“, SignedBy „*“ { permissions java.io.FilePermission „read,write“, „/applets/tmp/*“; permissions java.net.SocketPermission „connect“, „*.example.com“; }; » Laufzeit-Repräsentation: java.security.Policy » Default-Policy = Sandbox » Plaintext in policy-Datei: default: /lib/security/java.policy benutzerdefiniert: /.java.policy » Spezielle Policy kann bei Applikation angegeben werden: appletviewer -Djava.policy==/home/users/dummy/policy
27
Policytool Folie: 27 …die Standard-Policy und ihre Einträge in übersichtlicher Form
28
Policytool Folie: 28 …ein grant-Eintrag mit den zugewiesenen Rechten (Permissions)
29
Policytool Folie: 29 …hier können bestimmte Rechte benutzerfreundlich vergeben werden
30
Policytool Folie: 30 zurück …ein Beispiel für einen Permissons-Eintrag: Hier wird eine willkürliche Netzwerkverbindung mit allen Rechten (accept, connect, listen, resolve) gewährt.
31
Sicherheitselemente- Protection Domain Folie: 31 – Protection Domain logisches Konstrukt zur Gruppierung von Objekten Objekte sind eindeutig Protection Domains(PD) zugeordnet Class Loader Konzept spezielle Domain: System Domain für System-Klassen(haben alle Rechte) a.class b.class c.class d.class PD A PD B Permissions KlasseDomainPermission
32
Sicherheitselemente- Secure Class Loader Folie: 32 Secure Class Loader – Implementierung des abstrakten Class Loader – zuständig für das Laden jeden Javacodes(Ausnahme: built-in-Klassen) » insbesondere für das Tracking von CodeSource und Signatur des mobilen Codes Applikationen in die Sandbox bringen – CLASSPATH kann beibehalten werden – Applikationen in CLASSPATH werden vom URLClassLoader geladen !!...und sind damit Gegenstand von Sicherheitsüberprüfungen – für System-Klassen gibt es ab JDK 1.2 einen neuen Pfad: Xbootclasspath...und werden mit dem Primordial ClassLoader geladen
33
Sicherheitselemente- Security Manager Folie: 33 – Security Manager » kann zur Laufzeit ausgetauscht werden! » Sicherheitsüberprüfung bei Instanziierung und Installation: RuntimePermission(„createSecurityManager“) RuntimePermission(„setSecurityManager“) » definiert ein allgemeines Interface für Sicherheitsüberprüfungen » alle check-Methoden durch checkPermission ersetzt bzw. neu implementiert z.B.: public void checkLink(String lib){ checkPermission(new RuntimePermission(„loadLibrary.“+lib); } weiter an Access Controller
34
Sicherheitselemente- Access Controller Folie: 34 –Access Controller (final) java.security.AccessController eigentliche Sicherheitsüberprüfung Unter welchen Umständen ist eine Anfrage (nicht)erlaubt? Implementierung des Stack Inspection Algorithmus Der Access Controller ist für die Zugriffsauthorisierung vor jedem sicherheitskritischen Zugriff verantwortlich Eine Klasse kann auch dynamisch Stack Ins. initiieren: checkPermission(Permission p) Der Access Controller führt dann die entsprechende Stack Ins.(checkPrivilege()) durch und liefert eine Entscheidung: - AccessControlException Zugriff erlaubt
35
Stack Inspection - allgemein Folie: 35 Zu klären: Wer darf welche kritischen Aktionen ausführen? Kontext: Thread Jeder Ausführungsthread hat einen eigenen Laufzeit-Stack. Jeder Stack besteht aus Frames. Jeder Frame besteht aus Methodenaufruf(Klasse) + Protection Domain Der aktuelle Kontext wird vollkommen durch die aktuelle Methodenaufruf- Sequenz bzw. Protection-Domain-Sequenz beschrieben. Beispiel: Spiele-Applet versucht, eine HighScore-Datei zu öffnen openHighScoreFile() java.io.FileInputStream () AccessController.checkPermission() Stack System Domain Protection Domain A
36
Stack Inspection Folie: 36 Problem: Applikation kann unsicheren Code enthalten.(oder andersherum) Java Applikation untrusted Code Java System Library Call vertrauenswürdig? (z.B. Browser)
37
Stack Inspection - Beispiel Folie: 37 Unsicherer UserCode verwendet vertrauenswürdigen Code. Wie funktioniert das? AccessController bietet hierfür die Methode doPrivileged(). Damit wird der JRE signalisiert, dass der Status der aufrufenen Klasse(Methode) zu ignorieren ist. Idee: Kapselung sicherheitskritischer Operationen in kleinstmögliche Blöcke. Java wrappt den gesamten enable/disable-Prozeß in ein Interface,das mit dem AccessController angesprochen werden kann: interface PrivilegedAction{ Object run(); } User Code Change Passwort- Applikation Datei öffnen
38
Stack Inspection - Beispiel Folie: 38 Unsicherer UserCode verwendet vertrauenswürdigen Code. Die Change Passwort-Applikation würde dementsprechend folgenden Code beinhalten: User Code Change Passwort- Applikation Datei öffnen public void changePassword(){ //eigene Rechte zum Öffnen der Datei benutzen AccessController.doPrivileged(new PrivilegedAction(){ public Object run(){ //Datei öffnen... return null; } }); //altes und neues Passwort verifizieren... }
39
Stack Inspection - Algorithmus Folie: 39 checkPrivilege(target){ //loop, newest to oldest stack frame foreach stackFrame{ if(local policy forbids access to target by class executing in stackFrame) throw ForbiddenException ; if(stackFrame has enabled privilege for target) return; if(stackFrame has disabled privilege for target) throw ForbiddenException ; } Stack Ins. Algorithmus, wie er im Access Controller implementiert ist
40
Access Controller – Security Manager Folie: 40 Access Controler versus Security Manager Access Controller immer installiert -- Sicherheitsüberprüfungen immer gewährleistet Access Controller garantiert Stack Inspection Algorithmus – eigener Security Manager kann u.U. einen korrupten Stack Ins. Algorithmus anbieten doPrivilege() nur in Access Controller unterstützt, nicht unbedingt in Security Manager – dieser Mechanismus könnte also u.U. ignoriert werden
41
Quellen Bücher: O Securing Java von Gary McGraw, Edward W. Felten O Java Network Security von Robert McGregor et. al. O Inside Java2 Platform Security von Li Gong Webressourcen: Folie: 41 Security Tutorial von Sun
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.