Johanna Fitzinger

Seminar aus Softwareentwicklung: Inside Java and .NET

2

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

3

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.

4

Aufweichung der Sandbox

JDK 1.2: flexibleres feinkörniges Sicherheitsmodell

JDK 1.1: Signierung von Applets

5

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

6

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

7

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 gebenfü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 Klassejava.lang.Virus -> wird vom Network Class Loader geladen

-> keinen Zugriff auf ‘protected‘ Elemente des packages java.lang

8

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 KlassendateiPhase 2: Semantische Überprüfungen Phase 3: Bytecode Verifikation

Phase 4: Verifikation symbolischer Referenzen

9

Security Manager

Der Security Manager überprüft ob Code potentiell gefährliche Operationen ausführen darfKritische 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),

10

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

checkRead() wird aufgerufen

Lesen erlaubt?

checkRead() returns

read wird ausgeführt

NO

YES

YES

NOcheckRead() throws Exception

Recht wird gewährt

11

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

12

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)

• Schlüsselpaar erzeugen: keytool -genkey -alias me •Jar-Archiv erstellen: jar cvf MeinArchiv.jar *.class•Signieren: jarsigner MeinArchiv.jar me

Sender: Empfänger:

13

Policy

Policy File: Rechte (Permissions) werden ‘Code Sources‘ zugeordnet.

Die zu gewährenden Rechte werden in .policy-Dateien gespeichert.

Bearbeiten des Policy Files mit Hilfe von: policytool (im JDK bzw. JRE enthalten) 

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"; };

14

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

15

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

16

Stack Inspection

alle Rufer werden überprüft Nur alle Rufer die Permission besitzen, darf auf die

Ressource zugegriffen werden

xyz

java.io.File

Systemressource

AllPermission

xyzPermission

FilePermission

AccessController

deleteFile()

delete()

check Permission(..) implies(..)

implies(..)

1

2

3

4 5

6

Danke für die Aufmerksamkeit!