Class Loader

Seminar aus Softwareentwicklung: Inside Java and .NET
Johanna Fitzinger
Sicherheitskonzept in Java
Das Sandbox Sicherheitsmodell:
Nicht vertrauenswürdige Programme
laufen in einer geschützten Umgebung ab.
Zugriff auf wichtige Systemressourcen
wird dem Programm nicht gestattet
Komponenten des Basis Sandbox Modells:
 Class Loader
 Class File Verifier
 Security Manager
2
Ursprüngliches Sandbox Modell
 JDK 1.0:
Das Sandkasten Sicherheitsmodell des JDK 1.0 untersagte nicht
vertrauenswürdigem Applet-Code unter anderem folgende Aktionen:
 Lesen oder Schreiben von der
lokalen Platte
 Netzwerkverbindung zu einem Host
aufzubauen mit Ausnahme des Hosts
von dem das Applet geladen wurde
 Einen neuen Prozess zu starten
 Eine neue DLL zu laden.
3
Aufweichung der Sandbox
 JDK 1.1: Signierung von
Applets
 JDK 1.2: flexibleres
feinkörniges Sicherheitsmodell
4
Spracheigenschaften
• keine Pointer-Arithmetik
• strenge Typprüfung
• Garbage Collection
• automatisches Prüfen von Arraylängen
• Zugriffsrechte (public, protected, private)
Einschränkung der Sichtbarkeit von Elementen
• Exception Handling
5
Class Loader
Aufgaben:
 Laden,Trennen und Verwalten von Klassen
 getrennte Namensräume für Klassen die von verschiedenen Class Loadern
geladen wurden
 Klassen aus verschiedenen Namensräume können nicht direkt interagieren
 Schutz der Java System-Klassen:
 Verhindern von Überschreibung der „trusted class libraries“
 Zugriffsrechte auf Elemente innerhalb der Systemklassen-Packages müssen
geschützt werden
 Code in Protection Domains einteilen
 Protection Domain definiert welche Rechte dem Code gegeben werden
6
Class Loader Architektur
 1 eingebauter Class Loader(Bootstrap Class Loader), der für das
Laden der Core-Klassen der JAVA API verantwortlich ist
 es kann bel. viele zusätzliche Class Loader geben
für Web-Browser z.B. gibt es den Applet Class Loader
 Class Loader bilden Hierarchie
 Oberster Class Loader: Bootstrap Class Loader
 Bevor ein Class Loader eine Klasse lädt, beauftragt er seinen
übergeordneten Class Loader, die Klasse für ihn zu laden.
Bsp: ‘Network Class Loader‘ möchte folgende Klassen laden:
java.lang.Integer -> wird vom Bootstrap Class Loader geladen
-> kein Überschreiben der Klasse
java.lang.Virus -> wird vom Network Class Loader geladen
-> keinen Zugriff auf ‘protected‘ Elemente des
packages java.lang
7
Class File Verifier
Der Class File Verifier prüft ob das Programm nach
den Regeln der JVM abläuft.
Phase 1: Strukturelle Überprüfung der Klassendatei
Phase 2: Semantische Überprüfungen
Phase 3: Bytecode Verifikation
Phase 4: Verifikation symbolischer Referenzen
8
Security Manager
 Der Security Manager überprüft ob Code potentiell
gefährliche Operationen ausführen darf
Kritische Aktionen:




Zugriff auf Systemproperties
Zugriffe auf das Dateisystem
Manipulation/ Zugriff auf Threads
Netzwerkzugriffe
 Definiert check-Methoden, die kritische Aktionen
überwachen:
z.B. checkRead(String file),
checkAccess(Thread t) ,
checkDelete(Sting file),
9
Anfrage an Security Manager
FileInputStream fis = new FileInputStream("Textdatei.txt");
Erzeugen des FileInputStream Objects
-> Security Manager muss um Erlaubnis gefragt werden
Ist ein Security
Manager installiert
NO
Recht wird gewährt
YES
checkRead() wird aufgerufen
Lesen erlaubt?
NO
checkRead() throws Exception
YES
checkRead() returns
read wird ausgeführt
10
Security Manager Implementierung
 Vor JDK Version 1.2. war die Klasse
java.lang.SecurityManager eine abstrakte Klasse.
 Um benutzerdefinierte Sicherheitsrichtlinien zu installieren musste man seinen
eigenen Security Manager schreiben, und von der Klasse
java.lang.SecurityManager ableiten
 Seit Java 2 konkrete Klasse, die eine default Implementierung
des Security Managers darstellt
 Eine benutzerdefinierte Sicherheitsrichtlinie wird, anstatt in Java-Code, in
einem ASCII-File, genannt policy file, definiert
 AccessControler überprüft Rechte
 Installieren des default Security Managers:
-Djava.security.manager
11
Code Signing
 Signatur stellt sicher:
 Code stammt von einem bestimmten Autor (Datenidentität)
 Code wurde auf dem Weg vom Autor zum Nutzer nicht verändert
(Datenintegrität)
Sender:
Empfänger:
• Schlüsselpaar erzeugen: keytool -genkey -alias me
•Jar-Archiv erstellen:
jar cvf MeinArchiv.jar *.class
•Signieren:
jarsigner MeinArchiv.jar me
12
Policy
 Policy File: Rechte (Permissions) werden ‘Code Sources‘ zugeordnet.
Die zu gewährenden Rechte werden in .policy-Dateien gespeichert.
keystore “.keystore“;
grant SignedBy "trustme" CodeBase "http://www.trustme.com/-" {
permission java.io.FilePermission "<<ALL FILES>>", "read, write,
delete, execute";
permission java.security.SecurityPermission "getPolicy";
};
Bearbeiten des Policy Files mit Hilfe von: policytool (im JDK bzw. JRE enthalten)
13
Protection Domains
 Wenn Typen durch einen Class Loader in die JVM
geladen werden, wird jedem Typ genau eine Protection
Domain zugeordnet.
 Eine Protection Domain:
 definiert alle Permissions, die einer bestimmten Code Source
gewährt werden.
 entspricht einem oder mehreren Grant-Statements in einem
Policy File
14
Access Controller
 AccessController ist die Instanz in der Java-API, die die
Verwaltung und Durchsetzung der Rechte kapselt
 Der Security Manager entscheidet nicht mehr selbst ob
kritische Operation ausgeführt wird, sondern ruft die
checkPermission(Permission perm) Methode des Access
Controllers auf

führt Stack Inspection durch und liefert eine Entscheidung:
AccessControlException
Zugriff erlaubt
15
Stack Inspection
 alle Rufer werden überprüft
 Nur alle Rufer die Permission besitzen, darf auf die
Ressource zugegriffen werden
1
deleteFile()
xyzPermission
FilePermission
xyz
2
delete()
implies(..)
AllPermission
java.io.File
4
6
check Permission(..)
5
implies(..)
3
Systemressource
AccessController
16
Danke für die Aufmerksamkeit!