johanna fitzinger n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Johanna Fitzinger PowerPoint Presentation
Download Presentation
Johanna Fitzinger

Loading in 2 Seconds...

play fullscreen
1 / 17

Johanna Fitzinger - PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on

Seminar aus Softwareentwicklung: Inside Java and .NET. Johanna Fitzinger. Das Sandbox Sicherheitsmodell : Nicht vertrauenswürdige Programme laufen in einer geschützten Umgebung ab . Zugriff auf wichtige Systemressourcen wird dem Programm nicht gestattet

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Johanna Fitzinger' - alma


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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 desBasis Sandbox Modells:

Class Loader

Class File Verifier

Security Manager

Sicherheitskonzept in Java
urspr ngliches sandbox modell
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.
aufweichung der sandbox
Aufweichung der Sandbox
  • JDK 1.1: Signierung von Applets
  • JDK 1.2: flexibleres feinkörniges Sicherheitsmodell
spracheigenschaften
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
class loader
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
class loader architektur
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

class file verifier
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

security manager
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),

anfrage an security manager
Anfrage an Security Manager

FileInputStream fis = newFileInputStream("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

security manager implementierung
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

code signing
Code Signing
  • Signatur stellt sicher:
    • Codestammt von einem bestimmten Autor (Datenidentität)
    • Codewurde auf dem Weg vom Autor zum Nutzer nicht verändert (Datenintegrität)

Empfänger:

Sender:

  • Schlüsselpaar erzeugen: keytool -genkey -alias me
  • Jar-Archiv erstellen: jar cvf MeinArchiv.jar *.class
  • Signieren:jarsigner MeinArchiv.jar me
policy
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 (imJDK 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";};

protection domains
Protection Domains
  • Wenn Typen durch einen Class Loader in die JVM geladen werden, wird jedem Typ genau eineProtection 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
access controller
Access Controller
  • AccessController ist die Instanz in der Java-API, die die Verwaltung und Durchsetzung der Rechte kapselt
  • Der Security Managerentscheidet 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

stack inspection
Stack Inspection
  • alle Rufer werden überprüft
  • Nur alle Rufer die Permission besitzen, darf auf die Ressource zugegriffen werden

deleteFile()

xyzPermission

1

FilePermission

xyz

2

delete()

implies(..)

AllPermission

java.io.File

5

4

check Permission(..)

implies(..)

6

3

Systemressource

AccessController