6.3 Zugriffsschutz in Java - inf.fu-berlin.de · 1 6.3 Zugriffsschutz in Java Zusätzlich zum...

1

6.3 Zugriffsschutz in JavaZusätzlich zum Schutz durch das Betriebssystem

JVM

BSgemäß Benutzer-Privilegien undSchutzstatus erlaubter Zugriff

gemäß Politik und Klasse erlaubter Zugriff

gewünschter Zugriff

Die Java Sicherheitspolitik gilt zusätzlich zu den Sicherheitsmechanismen des Betriebssystemsauf dem Java läuft. Eine Java-Anwendung mit großzügiger Sicherheitspolitik kann versuchen,die Passwortdatei zu lesen, aber wenn der Benutzer, welcher die Anwendung laufen lässt, dieBerechtigung zum Lesen der Passwort-Datei nicht besitzt, wird die Java-Anwendung nicht dieDatei lesen können. Die globale Zugriffsschutzstrategie ist der Schnitt der Strategie für dieJava-Anwendung und der Strategie des Betriebssystems.

2

6.3 Zugriffsschutz in Java

Java-Spracheigenschaften erhöhen Sicherheit

• keine Pointer-Arithmetik, daher keine ungültigenSpeicherzugriffe

• Automatisches Speichermanagement• Garbage Collection• automatisches Prüfen von Arraylängen• strenge Typisierung, daher keine illegalen Casts• Zugriffsrechte, Einschränkung der Sichtbarkeit von Elementen• Klassen, Variablen und Methoden können als final deklariert

werden, daher keine weiter Ableitung der Klasse, Verändern vonVariablenwerten oder Überschreiben von Methoden

• Execeptions ermöglichen definierte und kontrollierteProgrammabbrüche

Java wurde mit dem Ziel entwickelt, einfach nutzbar zu sein. Die Hoffnung war, dass dies dieFehler von Programmieren verglichen mit anderen Programmiersprachen wie C oder C++minimiert und somit die Sicherheit der Programme erhöht wird. Die Sicherheit in Java wirddurch einige Eigenschaften erhöht: Java besitzt, anders als C oder C++, keine Pointer, so dasskeine ungültigen Speicherzugriffe möglich sind. Java besitzt ein automatischesSpeichermanagement, Garbage Collection, ein automatisches Prüfen von String- undArraylängen, betrachtet Zugriffsrechte und schränkt die Sichtbarkeit auf Elementen ein.Außerdem können in Java Klassen, Variablen und Methoden als final deklariert werden,womit eine weitere Ableitung der Klasse, das Verändern von Variablenwerten und dasÜberschreiben von Methoden nicht mehr möglich ist. Exceptions ermöglichen definierte undkontrollierte Programmabbrüche.

3


Sichtbarkeitprivate: nur Code der Klassedefault (package): Code der Klasse oder selbes Paketprotected: Code der Klasse, selbes Paket oder Subklassepublic: von jeder anderen Klasse

Beurteilung: schützt Code vor Codestatisch, ohne dynamische Prüfungenunterstützt least-priveledge-Prinzipfördert Programmsicherheit

Jede Entität eines Java-Programms hat ein Zugriffsschutzlevel:

private: Die Entität kann nur von Code innerhalb der Klasse aufgerufen werden, in der dieEntität definiert ist.

default (or package): Die Entität kann von Code aufgerufen werden, der innerhalb der Klasseder Entität definiert ist oder von einer Klasse, die im Paket der Entität enthalten ist.

protected: Die Entität kann nur von Code aufgerufen werden, welcher in der Klasse derEntität enthalten ist, von Klassen desselben Pakets oder von einer Subklasse.

public: Auf die Entität kann von jeder anderen Klasse aus zugegriffen werden.

4

6.3 Zugriffsschutz in JavaSicherheitsmechanismen der JVM

Class File VerifierStellt sicher, das nur berechtigter Java Bytecode ausgeführt wird.

Überprüfung erfolgt in vier Schritten:1. Format für Java-Klassen wird geprüft.2. Integrität der Klasse wird geprüft (z.B. dass die Klasse von

einer nicht finalen Klasse abgeleitet ist)3. Bytecode Verifier: Bytcode wird nach unzulässigen Instruktionen überprüft, z.B. richtige Anzahl und Typen von Parametern, Variablen sind initialisiert etc.4. Überprüfung von Verweisen auf Klassen sowie auf Methoden

und Attribute anderer Klassen (z.B. ob referenzierte Methodeüberhaupt existiert)

Die Virtuelle Maschine verbirgt Besonderheiten und Gefahren der ausführenden Architektur undüberwacht Programmausführung und Rechte. Der Java Compiler und der Class File Verifier stellensicher, dass nur berechtigter Java Bytecode ausgeführt wird. Die Überprüfung der Binärdaten erfolgt invier Schritten, von denen im ersten die Einhaltung des im Sprachstandard vorgegebenen Formats fürJava-Klassen sichergestellt wird. Die Struktur beinhaltet u. a. Informationen zur Version der Klasse,übergeordneten Klassen, Methoden und Attributen. Im zweiten Schritt wird die Integrität der Klassegeprüft, z.B. ob das Untersuchungsobjekt von einer gültigen, nicht finalen Superklasse abgeleitet wurde.Ist die Klasse vom Typ Object, so gilt diese Einschränkung nicht. Im dritten Schritt folgt der Aufruf desBytecode Verifiers, dem wohl wichtigsten, aber auch komplexesten Bestandteil des Class File Verifiers.Er überprüft den Bytecode vor dessen Ausführung nochmals auf unzulässige Instruktionen. Dazu zähltder Gebrauch der Parameter, die in richtiger Anzahl und korrektem Datentyp einem Aufruf folgenmüssen. In Schritt 4 werden alle Verweise auf andere Klassen sowie auf Methoden und Attributeanderer Klassen verfolgt und überprüft.

5

6.3 Zugriffsschutz in JavaClass Loader

definiert lokalen Namensraum, der gefährlichen Code von derBeeinflussung korrekten und sicheren Codes abhält.

Jeder Class Loader hat einen eigenen Namensraum (verhindert dasLaden mehrerer Klassen mit demselben Namen).

Namensräume sind „Schutzschild“ zwischen Klassenunterschiedlicher Namensräume:

Innerhalb eines Namensraums können Klassen kommunizieren(z.B. über public-Methoden).

Klassen in unterschiedlichen Namespaces (von unterschiedlichen Class Loadern) können nicht direkt kommunizieren.

Der Klassenlader (class loader) definiert einen lokalen Namensraum (namespace), welcher dazu benutztwerden kann, gefährlichen Code von der Beeinflussung korrekten und sicheren Codes abzuhalten. EinNamespace ist eine Menge unabhängiger und eindeutiger Namen (ein Name pro geladener Klasse).Jeder Class Loader besitzt solch einen eigenen Namespace. Falls z.B. eine Klasse Auto in einenNamespace geladen wird, ist es danach unmöglich eine weitere Klasse mit dem Namen Auto in diesenNamespace zu laden. Es ist jedoch möglich mehrere Auto-Klassen in eine Virtual Machine zu laden,solange sich diese in unterschiedlichen Namespaces befinden (von unterschiedlichen Class Loaderngeladen werden). Namespaces legen eine Art Schutzschild zwischen Klassen unterschiedlicherNamespaces: Klassen in identischen Namespaces können über die gewohnten Möglichkeitenmiteinander kommunizieren, z.B. über mit dem Schlüsselwort public definierte Methoden. Sobald sichzwei Klassen aber in unterschiedlichen Namespaces befinden, also von unterschiedlichen ClassLoadern geladen wurden, ist es für diese nicht einmal möglich, die Existenz der jeweils anderenfestzustellen, solange der Programmierer dies nicht explizit ermöglicht.

6


Class Loader bilden eineHierarchie (seit JDK1.2).

Bootstrap Class Loader istverantwortlich für das Laden derCore-Klassen der JAVA API.Werden als trusted angesehen.

Benutzerdefinierte Class Loaderladen restliche Klassen (z.B. derausgeführten Applikation)

BootsrapClass Loader

Class Loader N

Class Loader 1

Seit Java Version 1.2 bilden die Class Loader eine Hierarchie. Die Class Loader wurden in einer Vater-Sohn Beziehung angeordnet. Der sogenannte Bootstrap Class Loader steht dabei in der Hierarchie ander Spitze. Dieser Class Loader ist nur für das Laden der Klassen der Core-Java API zuständig. Für dasLaden anderer Klassen, wie z.B. die Klassen der ausgeführten Applikation, sind seit Version 1.2benutzerdefinierte Class Loader verantwortlich.

7

6.3 Zugriffsschutz in JavaVorgang beim Laden einer Klasse:

• Class Loader 1 möchte Klasse K laden.• Class Loader 1 fragt Class Loader 2, ob er K

laden kann.• ...• Class Loader N fragt Bootstrap Class Loader,

ob er Klasse K laden kann.• Wenn der Bootstrap Class Loader die Klasse K

hat, so wird sie zum Class Loader 1hindurchgereicht.

• Wenn der Bootstrap Class Loader die Klasse Knicht hat, so versucht der Class Loader N dieKlasse zu laden.

• ....

BootsrapClass Loader

Class Loader N

Class Loader 1

Möchte eine Applikation eine Klasse laden, so gibt der erste Class Loader die Anfrage an seinenVaterknoten weiter, der selbst die Anfrage wieder an seinen Vaterknoten weiterleitet. Der letzte Knotenin der Hierarchie ist der Bootstrap Class Loader. Dieser sucht die zu ladende Klasse in der Java API.Findet er die Klasse nicht, so gibt er die Anfrage wieder an seinen Sohn Class Loader weiter, derebenfalls versucht die Klasse zu laden usw. Kann der Bootstrap Class Loader jedoch die Klasse laden,so gibt er die Klasse an seine Sohnknoten weiter, die dann ihrerseits nicht mehr versuchen die Klasse zuladen.

8

6.3 Zugriffsschutz in JavaLadevorgang verhindert, dass man trusted-Klassen (z.B.java.lang.String) durch eigene Klassen überschreibt.

Anderes Beispiel:Angreifer schreibt java.lang.Virus.Anfrage zum Laden von java.lang.Virus gelangt zunächst zumBootstrap Class Loader, der zwar das Paket java.lang, aber dieKlasse nicht findet.Alle anderen Class Loader der Hierarchie finden die Klasseauch nicht, so dass java.lang.Virus vom Class Loader desAngreifers geladen wird.

Frage: Kann java.lang.Virus nun auf die Klassen (z.B. protected) imPaket java.lang zugreifen?

Nein, da die Pakete java.lang von verschiedenen Class Loaderngeladen wurden (und somit in verschiedenen runtime packagessind).

Der Class Loader verhindert das Verändern von trusted class libraries. Trusted class libraries sind diePakete, die von der Java Virtual Machine als definitiv sicher angesehen werden. Dazu gehören dieKlassen der Core Java API. Wenn ein benutzerdefinierter Class Loader beispielsweise versuchen würde,eine eigenen java.lang.String Klasse zu laden, würde diese Anfrage als erstes bis zum Bootstrap ClassLoader nach oben geleitet. Dieser würde feststellen, dass das Paket java.lang zur Java API gehört unddie Referenz auf diese Klasse zurückgeben.

Betrachten wir ein zweites Beispiel. Angenommen ein Programm möchte die Datei java.lang.Virusladen, die die Virtual Machine angreifen soll. Analog zum ersten Beispiel würde auch diese Anfrage bisganz nach oben delegiert werden, der Bootstrap CL würde feststellen, dass er zwar das Paket java.langkennt, aber die Klasse nicht enthalten ist und würde zurückgeben, dass er die Klasse nicht laden kann.Da auch alle anderen übergeordneten Class Loader die Datei nicht in ihrem Bereich finden können,würde sie also, wie vom Angreifer gewünscht, von dem eigenen Class Loader geladen. Da diese imPaket java.lang liegt könnte man jetzt davon ausgehen, dass diese die gleichen Rechte hat, wie jedeKlasse in diesem Paket, beispielsweise auf mit dem Schlüsselwort protected geschützte Methoden undAttribute zuzugreifen. Dies ist aber nicht möglich, da die java.lang API Pakete von einem anderen ClassLoader geladen wurden, als die java.lang.Virus Klasse. Hier kommt der Begriff des runtime packagesins Spiel, der bedeutet, dass sich zwei (oder mehrere) Klassen nur dann im gleichen runtime packagebefinden, wenn sie den gleichen Paketnamen haben und sie vom gleichen Class Loader geladen wurden.Da sich, um auf packagesichtbare Variablen und Methoden zugreifen zu können, die beiden Klassen imgleichen runtime package befinden müssen ist es der hier beispielhaft beschriebenen java.lang.VirusKlasse also nicht möglich, die java.lang Klassen der API zu beeinflussen.

9


Security Manager (und Access Controler in Java 2)

Zugriffe auf Ressourcen werden vom Security Managerder JVM geprüft, z.B.

- Netzwerkzugriffe - alle Operationen zum Manipulieren von und der

Zugriff auf Threads- der Zugriff auf Systemressourcen- Zugriffe auf das Dateisystem- das Aufrufen von lokalen Programmen undBetriebssystem-Kommandos

Der Zugriff zu sicherheitskritischen Ressourcen läuft über die Java Virtual Machine und wird vorherdurch den Security Manager geprüft. Der Security Manager schränkt die Aktionen von nichtvertrauenswürdigem Code auf ein Minimum ein. Die Operationen, die als gefährlich eingeschätztwerden und deshalb mit dem Security Manager kontrolliert werden können, sind beispielsweise:

· Netzwerkzugriffe

· alle Operationen zum Manipulieren von und der Zugriff auf Threads

· der Zugriff auf Systemressourcen

· Zugriffe auf das Dateisystem

· das Aufrufen von lokalen Programmen und Betriebssystem-Kommandos

10


Definiert check-Methoden, die kritische Aktionenüberwachen:

z.B. checkRead(String file), checkAccess(Thread t) , checkDelete(Sting file)

Vor JDK 1.2 war java.lang.SecurityManager eineabstrakte Klasse.

Benutzer mussten eigenen Security Manager schreibenund von der Klasse java.lang.SecurityManager ableiten.

Der Sicherheits-Manager ist ein Objekt, das für jede kritische Operation eine Methode zur Verfügungstellt, welche für die entsprechende Operation überprüft, ob sie ausgeführt werden darf oder nicht.Beispielsweise wird die Methode public void checkDelete(String file) des Security Managers von derJava API immer aufgerufen, bevor eine Datei gelöscht wird. Diese Methode muss überprüfen, ob die alsParameter angegebene Datei gelöscht werden darf und wenn dies nicht der Fall ist, eine Exceptionerzeugen, so dass die Operation abgebrochen wird.

Vor JDK Version 1.2. war die Klasse java.lang.SecurityManager eine abstrakte Klasse. Umbenutzerdefinierte Sicherheitsrichtlinien zu installieren musste man seinen eigenen Security Managerschreiben und von der Klasse java.lang.SecurityManager ableiten. Sobald eine Applikation dann denSecurity Manager instantiiert und installiert kümmert sich der Security Manager um die Einhaltung derSicherheitsrichtlinien, die durch die check-Methoden definiert wurden.

11

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

NO checkRead() throws Exception

Recht wird gewährt

Dieses Diagramm zeigt an einem Beispiel die bei der Ausführung einer sicherheitskritischenOperation nötigen Schritte. Wenn keine Security Manager installiert ist, wird der Zugriff sofortgewährt. Gibt es einen Security Manager, wird die entsprechende check()-Methode desinstallierten Security Managers aufgerufen und der Zugriff von diesem überprüft.

12


Seit JDK 1.2 ist java.lang.SecurityManager einekonkrete Klasse, die eine Default-Implementierung desSecurity Managers darstellt.

Installieren des default Security Managers über dieKommandozeile mittels -Djava.security.manager

Eine benutzerdefinierte Sicherheitsrichtlinie wird,anstatt in Java-Code, in einem ASCII-File (policy file)definiert.

Seit Java 1.2 ist die Klasse java.lang.SecurityManager eine konkrete Klasse, die eine Default-Implementierung des Security Managers darstellt. Der Default Security Manager kann durch Aufruffolgender Option über die Kommandozeile installiert werden: -Djava.security.manager.Benutzerdefinierte Sicherheitspolitiken werden in einem ASCII-File, genannt Policy File, definiert undnicht mehr in Java-Code implementiert (d.h. in der abgeleiteten Klasse des abstraktenSecurityManagers) .

13


Zugriff auf Systemressourcen läuft weiterhin überSecurity Manager, dieser implementiert aber nicht mehrdie Zugriffsregeln.

Security Manager reicht Anfrage an den AccessController weiter.

Access Controler verwendet das Poilcy File zurZugriffsentscheidung.

Beim Zugriff auf Systemressourcen wird in Java 2 zwar weiterhin der Security Manager konsultiert, dieZugriffsregeln allerdings sind nicht mehr in ihm implementiert, sondern werden an den AccessController weitergeleitet. Wenn also eine check-Methode des default Security Managers aufgerufenwird, so wird der Request an die Klasse AccessControler weitergeleitet. Der Access Controllerverwendet die Information des Policy Files, um zu entscheiden, ob die Aktion erlaubt werden soll odernicht.

14


Sandboxmodell JDK 1.0

Sandbox ist eine beschränkteUmgebung für nichtvertrauenswürdigen Code

Lokaler Code ist vertrauenswürdigund hat vollen Zugriff aufSystemressourcen.

Code aus dem Internet (Applet) istnicht vertrauenswürdig.

Security Manager bestimmt dieerlaubten Zugriffe.

Das originale Java Sicherheitsmodell, bekannt als „Sandbox" Modell, stellt eine sehrbeschränkte Umgebung zur Verfügung, in der nicht vertrauenswürdiger Code ausgeführtwerden kann. Im Sandbox-Modell ist lokaler Code vertrauenswürdig und hat vollen Zugriff zuden Systemressourcen, wie das Dateisystem. Code, der aus dem Internet geladen wurde(Applet) ist nicht vertrauenswürdig und kann nur auf die beschränkten Ressourcen in derSandbox zugreifen. Der Security Manager ist verantwortlich, zu bestimmen, welcheRessourcenzugriffe erlaubt sind.

15


In der Sandbox sind folgende Aktionen nicht möglich.

• Lesen oder Schreiben auf der lokalen Platte

• Eine Netzwerkverbindung zu einem Rechner aufbauenaußer dem Rechner, von dem das Applet geladenwurde.

• Einen neuen Prozess starten

• Eine neue DLL laden

Aktionen, die Code in der Sandbox nicht möglich sind, zeigt die Folie.

16


Sandboxmodell JDK 1.1Signierung von Applets

Digital signierte Appletswerden wie lokaler Codebehandelt.

Öffentlicher Schlüssel zumVerifizieren mussvertrauenswürdig sein.

Unsignierte Applets laufenweiterhin in der Sandbox

JDK 1.1 führte „signierte Applets„ ein. Ein digital signiertes Applet wird wie lokaler Codebehandelt, mit vollen Zugriff auf die Ressourcen, wenn der öffentliche Schlüssel zumVerifizieren der Signatur vertrauenswürdig ist. Unsignierte Applets werden weiterhin in derSanbox ausgeführt. Signierte Applets werden mit ihrer Signatur in signierten JAR (JavaARchive) Dateien geliefert.

17

6.3 Zugriffsschutz in JavaSandboxmodell JDK 1.2

Code wird mit einer Sicherheits-politik assoziert.

Sicherheitspolitik enthälteine Menge von Permissions(z.B. Erlaubnis zum Zugriff aufSystemressource oder Verbindungzu einem Rechner bzw. Port).

Sicherheitspolitik wird vom Benutzeroder Administrator definiert.

JDK 1.2 führt mehrere Erweiterungen bzgl. JDK 1.1. ein: Erstens, der gesamte Code, egal oblocal oder remote, kann nun mit einer Sicherheitspolitik (security policy) assoziiert werden.Die Sicherheitspolitik definiert eine Menge von Permissions und muss bei einem Benutzeroder dem Systemadministrator konfiguriert werden. Jede Permission spezifiziert einenerlaubten Zugriff auf eine bestimmte Ressource, z.B. Lese- und Schreibzugriff auf eine Dateioder ein Verzeichnis oder die Erlaubnis sich zu einem bestimmten Host oder Port zu verbinden.

18

6.3 Zugriffsschutz in JavaSandboxmodell JDK 1.2

Code ist in Domänen (domains)aufgeteilt.

Domäne ist eine Menge vonKlassen, deren Instanzen diegleichen Rechte haben.

Extreme von Domänen: vollerZugriff und Sandbox-Konfiguration.

Die Laufzeitumgebung organisiert den Code in Domänen (domains), jede betrifft eine Mengevon Klassen, deren Instanzen die gleichen Rechte gewährleistet werden. Eine Domäne kannwie eine Sandbox konfiguriert sein, so dass Applets weiterhin in einer beschränktenUmgebung ausgeführt werden können. Der linke Pfeil in der Abbildung entspricht einerDomäne, in der dem Code vollen Zugriff gewährt wird. Der Pfeil auf der rechten Seiterepräsentiert das andere Extrem. Diese Domäne entspricht der Sandbox. Die dazwischenliegenden Domänen haben weniger Zugriffsrechte als der volle Zugriff aber mehr als dieSandbox.

19


Wenn Klassen durch einen Class Loader in die JVM geladenwerden, wird jeder Klasse genau eine Domäne zugeordnet.

Threads, die mehrere Domänen umfassen, haben den Schnitt derPermissions dieser Domänen.

a.classb.classc.classd.class

Dom A

Dom B

Permissions

Permissions

Klasse Domain Permission

Eine Domäne umfasst eine Menge von Klassen, deren Instanzen dieselbe Menge von Permissionshaben. Die Java Anwendungsumgebung verwaltet eine Abbildung vom Code (Klassen und Instanzen)zu ihren Domänen und dann zu ihren Permissions. Threads können komplett in einer Domäne ablaufenoder können mehrere Domänen umfassen. In diesem Fall gilt, dass die Menge der Permissions für denThread der Schnitt der Permissions aller Domänen ist, die der Thread benutzt.

20

6.3 Zugriffsschutz in JavaPermissions repräsentieren denZugriff auf Systemressourcen.

Abstrakte Klassejava.security.Permission

Neue Permissions erweitern dieseKlasse.

Actions sind die erlaubten Aktionen aufeinem Objekt, z.B.

perm1 = newFilePermission(p1,"read,write");perm2 = newFilePermission(p2,"write,read");

Die Permission-Klassen repräsentieren den Zugriff zu Systemressourcen. Die java.security.PermissionKlasse ist eine abstrakte Klasse, von der Unterklassen für bestimmte Zugriffe abgeleitet werden können.Ein Beispiel einer solchen Permission zum Lesen einer Datei „abc“ im Verzeichnis /tmp zeigt derfolgende Code: perm = new java.io.FilePermission("/tmp/abc", "read"). Neue Permissions können vonder Permission-Klasse oder Unterklassen abgeleitet werden. Die abstrakte Methode implies muss vonneuen Permission-Klassen implementiert werden. Grob gesehen, bedeutet „a implies b“, dass jemandem,dem die Permission A gewährt wird, auch die Permission b gewährt wird. Die meisten Permissionsenthalten eine Liste von „Actions“ die sagt, welche Aktionen für das Objekt erlaubt sind. In einemjava.io.FilePermission Objekt könnte die Aktionsliste beispielsweise aus „read, write“ bestehen.

21


Beipsiel: java.io.FilePermission

Aktionen sind read, write, delete und execute

import java.io.FilePermission;

FilePermission p = new FilePermission("myfile", "read,write");FilePermission p = new FilePermission("/home/gong/", "read");FilePermission p = new FilePermission("/tmp/mytmp", "read,delete");FilePermission p = new FilePermission("/bin/*", "execute");FilePermission p = new FilePermission("*", "read");FilePermission p = new FilePermission("/-", "read,execute");FilePermission p = new FilePermission("-", "read,execute");FilePermission p = new FilePermission("<<ALL FILES>>", "read");

Ein Beispiel einer speziellen Permission ist die java.io.FilePermission. Diese gibt die Erlaubnis für denZugriff auf eine Datei oder ein Verzeichnis (spezifiziert im Parameter path). Die Aktionen für denParameter actions sind read, write, delete, und execute. Die Folie zeigt einige Beispiele ihrerAnwendung. Das Beispiel FilePermission p = new FilePermission("/home/gong/", "read"); gibtbeispielsweise die Permission zum Lesen des Verzeichnisses (d.h. das Auflisten der darin enthaltenenDateien), jedoch nicht das Leserecht auf den Dateien selbst. Um auch die Dateien des Verzeichnisseslesen zu können, muss man dies explizit durch den Dateinamen angeben oder durch „*“ (alle Dateienim Verzeichnis) bzw. „-“ (alle Dateien im Verzeichnis und allen Unterverzeichnissen). Mit <<ALLFILES>> wird die Permission auf allen Dateien des Systems gewährt.

22


Beispiel:java.lang.RuntimePermission

Permission braucht nicht unbedingt keine Aktionen.

createClassLoader getClassLoader

setContextClassLoader setSecurityManagercreateSecurityManager exitVMmodifyThread stopThreadmodifyThreadGroup getProtectionDomainreadFileDescriptor writeFileDescriptor

...

Die java.lang.RUntimePermission ist ein Beispiel einer Permission, die keine Aktionenerfordert. Das Zielobjekt der RuntimePermission kann als String repräsentiert werden ohnedas eine Aktion mit diesem Zielobjekt verbunden wäre. RuntimePermission("exitVM")soezifiziert zum Beispiel die Permission die Java Virtual Machine zu verlassen.

23


Die implies-Methode vereinfacht den Vergleich vonPermissions und gibt einen Überblick über dieMächtigkeit einer Permission.

Beispiel:

java.io.FilePermission("/tmp/*", "read")impliziert

java.io.FilePermission("/tmp/a.txt", "read")

Um Permissions besser miteinander vergleichen zu können, muss jede Permission die implies-Methodeimplementieren. Betrachten wir zum Beispiel java.io.FilePermission("/tmp/*", "read"), so impliziertdiese Permission java.io.FilePermission("/tmp/a.txt", "read").

24

6.3 Zugriffsschutz in JavaImplikation ist nicht immer offensichtlich.

Wenn Applet die Permission zum Schreiben auf dem Dateisystemhat, kann es die JVM Runtime-Umgebung austauschen, in der esdann alle Permissions hat.

Wenn ein Applet die RuntimePermission zum Erzeugen von ClassLoadern hat, hat es auch viele Permissions des Class Loaders.

Gefahren der Permissions sind unter

http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermRisksbeschrieben.

Nicht bei allen Permissions ist diese Implikation jedoch für den Programmierer so offensichtlich.Nehmen wir ein Applet an, welches die Permission write zum Schreiben auf dem gesamten Dateisystemhat. Dies erlaubt dem Applet u.a. die JVM Runtime-Umgebung zu ersetzen. Damit hat dann das Appletalle Permissions. Ein anderes Beispiel ist ein Applet, welcher die Runtime Permission gewährt wird,um Class Loader zu erzeugen. Damit werden dem Applet auch viele Permissions des Class Loadersgewährt. Andere „gefährliche“ Permissions und ihre Risiken sind unterhttp://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermRisks beschrieben.

25


Dies erlaubt einem Angreifer denClass Loader einer Klasse zuerhalten. Jedoch können auch alleanderen Klassen geladen werden,auf die der Angreifer keinen Zugriffhat.

Erhalten einesClass Loaders

getClassLoader

Anwendungen können ihren eigenenClass Loader erzeugen, mit dem sieihre eigenen Klassen ins Systemladen. Diese Klassen können in jedeDomäne gepackt werden, womit denKlassen die Domänen-Permissionsgewährt werden.

Erzeugt einenClass Loader

createClassLoader

RisikoWas erlaubtdie Permission

java.lang.RuntimePermission

Diese und die nächste Folie zeigen ein Beispiel für die Risiken, die sich durch die Zuordnung derRuntimePermission ergeben können.

26


Erlaubt Denial-of-Service-AttackenAnhalten derJVM

exitVM

Dies erlaubt Code den SecuriytManager gegen einen wenigerrestriktiven Security Managerauszutauschen, um dieZugriffüberprüfungen desursprünglichen Security Managerszu umgehen.

Setzt einenSecurityManager

setSecurityManager

RisikoWas erlaubtdiePermission

java.lang.RuntimePermission

..und viele weitere Gefahren !

27


Policy-Objekt repräsentiert die Politik einer JavaAnwendung.

Politik ist in einer oder mehreren Politik-Konfigurations-dateien spezifiziert.

Beispiel eines Politik-Konfigurationseintrages:

grant codeBase "file:/home/sysadmin/" {permission java.io.FilePermission"/tmp/abc", "read"; };

Die Sicherheitspolitik für eine Java Anwendung wird durch ein Policy-Objekt repräsentiert. Damit einApplet (oder eine Anwendung, die unter einem Security Manager läuft) geschützte Aktionen (wie dasLesen oder Schreiben von Dateien) durchführen kann, müssen ihm die Permissions für diese Aktiongewährt werden. Eine Ausnahme ist, das Code immer das Recht hat, Dateien von seiner CodeSource zulesen. Es werden in diesem Fall keine Permissions benötigt. Es kann mehrere Instanzen des Policy-Objekts geben, aber immer nur eine ist zu einem Zeitpunkt für die Zugriffsschutzentscheidung relevant.Die Politik kann in einem oder mehreren Politik-Konfigurationsdateien spezifiziert werden. Die Politik-Dateien spezifizieren welche Permission für welchen Code stammend von welcher Quelle erlaubt sind.Ein Beispieleintrag in einer Politik-Datei zeigt die Folie, bei der Code vom Verzeichnis /home/sysadmindie Erlaubnis zum Lesen des Verzeichnisses /tmp/abc gegeben wird.

28


Politik-Dateien können im Textedtior oder mit dem Toolpolicytool erstellt werden.

Systemweite Standard-Politik unterjava.home\lib\security\java.policy (Windows)

(Optionale) Benutzerspezifische Politik unteruser.home\.java.policy (Windows)

Politik-Objekt wird mit Systempolitik initialisiert und diebenutzerspezifische wird (fals vorhanden) hinzugefügt.

Eine Politik-Datei kann in einem Texteditor geschrieben werden oder mittels dem Policy Tool(Kommando polictyTool) erstellt werden. Es gibt eine systemweite Standard Politik-Datei injava.home/lib/security/java.policy (Solaris) bzw. java.home\lib\security\java.policy (Windows) und eineoptionale benutzerspezifische Politik-Datei unter user.home/.java.policy (Solaris) bzw.user.home\.java.policy (Windows). Wenn das Politik-Objekt initialisiert wird, wird zunächst diesystemweite Politik geladen und dann die benutzerspezifische zugefügt.

29


Policy-Datei-Format enthält einen Keystore-Eintrag und eine Listevon „grant“-Einträgen.

Keystore ist Datenbank für private Schlüssel mit Zertifikaten für dieöffentlichen Schlüssel (siehe Kryptographie 3.6.5.1)

Keystore benutzt öffentliche Schlüssel der in den „grant“-Einträgenangegebenen Signierenden.

Syntax:keystore "some_keystore_url", "keystore_type";

keystore_type gibt das Speicher- und Datenformat desKeystores an.

Eine Policy-Konfigurationsdatei kann einen „keystore“-Eintrag und null oder mehr „grant“-Einträgeenthalten. Ein Keystore ist eine Datenbank privater Schlüssel mit entsprechenden X.509 Zertifikaten fürdie zugehörigen öffentlichen Schlüssel. Der Keystore wird dazu benutzt, die öffentlichen Schlüsselderjenigen zu ermitteln, die in den „grant“-Einträgen als Signierende angeben sind. Der Keystore-Eintrag hat die folgende Syntax: keystore "some_keystore_url", "keystore_type";

Hierbei spezifiziert "some_keystore_url" die URL des Keystores und "keystore_type" spezifiziert(optional) den Keystoretyp. Ein Keystortyp definiert das Speicher- und Datenformat der Keystore-Informationen und die Algorithmen zum Schutz der Schlüssel.

30


Ein „grant“-Eintrag gibt eine Menge von Permissions an spezifiziertenCode.

Beispiele:

Permission a.b.Foo für Code signiert von Roland:grant signedBy "Roland" { permission a.b.Foo; };

FilePermission für jeden Code (unabhängig vom Signierenden oder dercodeBase):grant {

permission java.io.FilePermission ".tmp", "read";};

Jeder „grant“-Eintrag besteht aus einem CodeSource und den gewährten Permissions. Die folgendenFolien zeigen einige Beispiele.

31


Zwei Permissions für Code signiert von Li und Roland:grant signedBy "Roland,Li" {

permission java.io.FilePermission "/tmp/*", "read";

permission java.util.PropertyPermission "user.*";

};

Zwei Permissions für Code signiert von Li und der Code stammt vonhttp://java.sun.com:

grant codeBase "http://java.sun.com/*",signedBy "Li" {permission java.io.FilePermission "/tmp/*", "read";permission java.io.SocketPermission "*", "connect";

};

32


Zwei Permissions für Code signiert von Li und Roland, nur wenn derBytecode für com.abc.TVPermission von Li signiert ist.grant signedBy "Roland,Li" {

permission java.io.FilePermission "/tmp/*","read";permission com.abc.TVPermission "channel-5",

"watch", signedBy "Li";};

33


Access Controller überprüft bei einem Zugriff, ob dieerforderlichen Permissions existieren.

Geschieht mittels Stack Inspection.

Code SourceSigners

Bytecode Identity

Java Runtime

Policy

Access Controller" Stack Inspection

Die Überprüfung auf ausreichende Rechte wird seit JDK1.2 von der Klasse AccessControllerbewerkstelligt. Dabei werden Maßnahmen ergriffen, um Missbrauch von Code mit mehr Rechten durchein Programm mit wenigen Rechten zu verhindern. Dies geschieht durch Überprüfung aller Rufer amCall Stack. Dieser Mechanismus wird als Stack Inspection bezeichnet.

34


Stack InspectionÜberprüft ob alle Aufrufer in der Ruferkette dieentsprechenden Permissions haben.

Class A

Class B

Class C

java.io.file

Systemressource

Domain 1

Domain 2

Domain 3

Domain 4

Stack Inspection

Access Controller prüftob die Permissionvorhanden ist.

Bei einer Stack Inspection wird geprüft, ob alle Methoden in der Ruferkette die entsprechendenPermissions besitzen. Nur wenn alle Rufer am Call Stack die entsprechende Permission besitzen, darfeine Aktion ausgeführt werden. Betrachten wir als Beispiel eine Klasse A, die eine Methode der KlasseB aufruft, die wiederum eine Methode der Klasse C aufruft, welche schließlich eine Methode der Klassejava.io.file aufruft. Die Klasse java.io.file veranlasst durch den Aufruf der Methode checkPermission(Permission perm) den Access Controller zur Überprüfung der Rechte. Der Access Controller für alleKlassen überprüfen, ob sie ausreichende Permissions zum Aufrufen der jeweiligen Methoden haben.Reichen die Permissions für eine Klasse nicht aus, so wird der Zugriff verwehrt.

35


Access Controller überprüft der Reihe nach, ob die Aufrufer aufdem Stack die geforderte Permission haben.

Überprüft die Permission mit der Methode implies() desProtectionDomain-Objekts.

public boolean implies(Permission permission)

Hat einer der Aufrufer nicht die benötigte Permission, so gibtder Access Controller eine AccessControlException zurück undder Zugriff auf die Systemressource wird nicht ausgeführt.

Der AccessController überprüft der Reihe nach alle Rufer am Stack auf die geforderte Permission,indem er die Methode implies(Permission p) aufruft. Die Methode implies() ist in der KlasseProtectionDomain deklariert. Als einzigen Parameter erwartet diese Methode ein Objekt vom TypPermission. Diese Methode überprüft ob eine Permission in der ProtectionDomain enthalten ist. Ist dasder Fall wird true zurückgegeben, andernfalls false. Stellt der AccessController während der StackInspection fest, dass einer der Rufer nicht über die geforderte Permission verfügt, wird die weitereÜberprüfung mit der Erzeugung einer AccessControlException abgebrochen und der Zugriff auf dieRessource kann nicht ausgeführt werden. Die Operation bricht ihrerseits mit einer SecurityExceptionab.

36


Java 2 SDK, v. 1.4 bietet zusätzlich zur Java Sicherheitsarchitektur:

Java Crytography Extension (JCE)Enthält z.B. Pakete für Verschlüsselung (symmetrisch,asymmetrsich, Block- und Strom), Schlüsselgenerierung, MessageAuthentication Code

Java Authentication and Authorization Service (JAAS)Enthält Pakte zur Authentifizierung und Zugriffskontrolle vonBenutzern.

Java Secure Socket Extension (JSSE)Enthält Pakte für sichere Internet-Kommunikation (z.B. SSL, TLS).

Neben dem Standard Java Sicherheitsmodell, gibt es Ergänzungen für weitereSicherheitsaspekte:

-Die Java Cryptography Extension (JCE) ist eine Menge von Paketen für Verschlüsselung,Schlüsselgenerierung und Message Authentication Code (MAC) Algorithmen.Verschlüsselung beinhaltet symmetrische, asymmetrische, Block- und Stromverschlüsselung.

-Der Java Authentication and Authorization Service (JAAS) ist eine Menge von Paketen zurAuthentifizierung und Zugriffskontrolle von Benutzern.

-Die Java Secure Socket Extension (JSSE) ist eine Menge von Paketen die eine sichereInternet-Kommunikation ermöglichen. Implementiert eine Java Version von Secure SocketsLayer (SSL) und Transport Layer Security (TLS) Protokollen. Enthält Funktionen für dieDatenverschlüsselung, Server-Authentifizierung, Nachrichtenintegrität und optional Client-Authentifizierung.

37


JAAS ist eine Ergänzung zur Java 2 SDKSicherheitsarchitektur

Die Java 2 SDK Sicherheitsarchitektur ist Code-zentriert,d.h. die Zugriffsentscheidung basiert auf der Frage:

Woher kommt der Code und wer hat ihn signiert?

JAAS ist Benutert-basiert, d.h. die Zugriffsentscheidungbasiert auf der Frage:

Wer führt den Code aus?

JAAS Autorisierung erweitert die Java Sicherheitsarchitekur. Die Java Sicherheitsarchitekturbenutzt eine Security policy, um zu spezifizieren, welche Zugriffsrechte einem Codezugewiesen werden. Diese Architektur ist Code-zentriert, d.h. die Permissions wurdenbasierend auf den Eigenschaften des Codes erteilt: woher kommt der Code und wer hat ihnsigniert. Mit der Integration von JAAS in das Java 2 SDK ist es nun möglich benutzerbasiertePermissions zu definieren. Somit basiert der Zugriffsschutz nun nicht nur auf dem Code derausgeführt wird, sondern auch darauf, wer den Code ausführt.

38


Java 2 Sicherheit ist Code-zentriert

CodeSourceCode Signierende

Permissions

Das Java Standardsicherheitsmodell ist Code-zentriert. In der Security Policy werden Permissionsaufgrund der Herkunft des Codes und des Signierenden des Codes vergeben.

39


Java 2 und JAAS

CodeSourceCode Signierende

Permissions

Benutzer

Mit JAAS kann in der Security Policy auch spezifiziert werden, an welchem Benutzer die Permissiongebunden ist.

40

JAAS AuthentifizierungWeist einem Benutzer, der eine Anwendung ausführt, eineauthentifizierte Benutzererkennung (Principal) zu.

Anwendungen sind unabhängig vom Authentifizierungsservice


Anwendung

LoginContext

LoginModule

Kerberos Smartcard Biometrie

Modul-konfiguration

Das Prinzip von JAAS ist, dass dem Benutzer, der die Anwendung ausführt (in der JAAS-Terminologie»Subject« genannt) eine oder mehrere authentifizierte Benutzerkennungen (als »Principals« bezeichnet)zugeordnet werden. Die JAAS Architektur erlaubt Anwendungen unabhängig vomAuthentifizierungsservice zu bleiben. Es kann beispielsweise eine Authentifizierung über Kerberos,Smartcards, Biometrie etc. erfolgen. Die Schnittstelle zwischen JAAS und einem Programm, das JAASbenutzt, ist die Klasse LoginContext aus dem Paket javax.security.auth.login.

41


LoginContext beschreibt

den Namen des Kontextes, der die Login-Modulkonfiguration spezifiziert (Modulkonfiguration stehtin einer Datei).

einen CallbackHandler, der Benutzerinteraktionen fürdas Modul durchführt (z.B. Abfrage eines Passworts)

Da Benutzer-Abfragen mit der Anwendung variieren, sindsie nicht direkt im Modul kodiert, sondern getrennt imCallbackHandler.

Ein LoginContext benötigt zwei Informationen:

1. Den Namen des Kontextes. Dieser Name identifiziert die Login-Modulkonfiguration, die für denKontext verwendet werden soll. Diese Modulkonfiguration steht in einer Datei.

2. Ein Exemplar der Klasse CallbackHandler. Dieses Objekt dient dazu, Benutzerinteraktionendurchzuführen, die die Module benötigen. Eine solche Interaktion könnte die Abfrage eines Passwortssein. Da die Form solcher Abfragen stark von der Anwendung abhängt (z. B. Kommandozeile odergrafischer Dialog), sind sie nicht in den Modulen selbst kodiert, sondern werden über einenCallbackHandler abgewickelt.

42


Verwendung von JAAS erfordert

1. Erstellen einer Konfigurationsdatei, in der das Authentifizierungsmodell eingetragen wird.2. Erstellen eines CallbackHandlers, der die Benutzerinteraktion durchführt.3. Erzeugen eines LoginContext, mit dessen Methode

login() das Login durchgeführt werden kann.

Für die Verwendung von JAAS sind daher drei Schritte durchzuführen:

1. Es ist eine Konfigurationsdatei zu erstellen, in der das gewünschte Authentifizierungsmoduleingetragen wird.

2. Es muss eine Unterklasse von CallbackHandler erstellt werden, in der die Benutzerinteraktiondurchgeführt wird.

3. Es muss ein LoginContext erzeugt werden, mit dessen Methode login() das eigentliche Logindurchgeführt werden kann.

43


Beispiel: Modulkonfiguration Demo

Demo { com.sun.security.auth.module.UnixLoginModulerequired debug=false;};

J2SE Standard-Login-Modul für Unix, das die UNIX Benutzer-ID,unter der die Anwendung läuft, zur Benutzererkennung (Principal)verwendet.

Benötigt keine Benutzerinteraktion (und damit keinenCallbackHandler), da direkt die Betriebssystem-Benutzererkennungbenutzt wird.

Das Modul com.sun.security.auth.module.UnixLoginModule ist ein Login-Modul, das standardmäßigbei J2SE dabei ist und Principals für Unix-Benutzer-IDs ausstellt, unter der das Programm ausgeführtwird. Dieses Modul erfordert keine Benutzerinteraktion und somit auch keinen speziellenCallbackHandler. Die Principals werden automatisch aus der Betriebssystem-Benutzerkennung erstellt.

44


Weitere Standard-Module sind

JndiLoginModule für eine Authentifizierunggegenüber einem LDAP-Verzeichnis.

Krb5LoginModule für die Anmeldung an einemKerberos-System.

KeyStoreLoginModule für eine Authentifizierunggegenüber einem Java Key Store.

Neben den beiden genannten Modulen werden standardmäßig z.B. noch folgende Module mitgeliefert:

Das JndiLoginModule für eine Authentifizierung gegenüber einem LDAP-Verzeichnis.

Das Krb5LoginModule für die Anmeldung an einem Kerberos-System.

Das KeyStoreLoginModule für eine Authentifizierung gegenüber einem Java Key Store.

45


Login-Kontext für die Konfiguration "Demo" erzeugen

try {loginContext = new LoginContext("Demo");// mit CallbackHandler// loginContext = new LoginContext("Demo„,// CallbackHandler);

}catch (LoginException e) {}

Durchführung des Logins

loginContext.login();

46


JAAS erlaubt mehrere Login-Module in einer Konfiguration

Demo {com.sun.security.auth.module.UnixLoginModule required debug=false;demo.MyLoginModule optional debug=false;

};

Tags in Konfiguration entscheiden, wie sich die gesamteAuthentifizierung bzgl. Der Modul-Authentifizierungenverhält.

Bei JAAS können Login-Module auch kaskadiert, d. h. nacheinander ausgeführt werden. Im Beispielder Folie wird zunächst eine Anmeldung mit dem UnixLoginModule und danach mit MyLoginModuledurchgeführt. Die Authentifizierung erfolgt dann in zwei Phasen: In der ersten Phase werden die Login-Informationen für alle Module ermittelt. Erst wenn alle Module diese erste Phase erfolgreichdurchlaufen haben, beginnt die zweite Phase, in der dem Benutzer die Principals hinzugefügt werden.Daher wird bei JAAS zwischen dem Ergebnis eines einzelnen Moduls und dem Ergebnis der gesamtenKette unterschieden. Bei JAAS kann für jedes einzelne Login-Modul konfiguriert werden, ob diePrincipals nur dann gewährt werden, wenn die gesamte Kette erfolgreich war, oder ob es bereits genügt,wenn das Modul selbst abgeschlossen wurde.

47


Tags für die Modulkonfiguration legen fest, ob

Modul Erfolg für den Erfolg der Gesamtanmeldung haben muss,

nachfolgende Module zur Ausführung kommen

Ausführung folgenderModule

Erfolgzwingend

Tag

neinneinjaja

immeroptionalnur bei Misserfolgsufficientnur bei Erfolgrequisiteimmerrequired

Die einzelnen Tags in der Modellkonfiguration legen fest, ob das betreffende Modul Erfolg haben muss,damit die Gesamtanmeldung noch als erfolgreich gilt. Es kann auch definiert werden, ob nachfolgendeModule überhaupt noch zur Ausführung kommen sollen. Die Tags sind im Einzelnen:

required Die Authentifizierung des Moduls muss erfolgreich sein, damit die Gesamtauthentifizierungerfolgreich ist. Nachgeordnete Login-Module werden in jedem Fall noch ausgeführt, unabhängig davon,ob die Anmeldung mit diesem Modul fehlschlägt.

requisite Die Authentifizierung des Moduls muss erfolgreich sein, damit die Gesamtauthentifizierungerfolgreich ist. Falls die Anmeldung mit diesem Modul fehlschlägt, ist auch dieGesamtauthentifizierung fehlgeschlagen und login() kehrt sofort zurück. Ist die Anmeldung mit diesemModul dagegen erfolgreich, werden nachgeordnete Login-Module auch noch ausgeführt.

sufficient Die Authentifizierung mit dem Modul braucht nicht zwingend erfolgreich sein, damit dieGesamtauthentifizierung erfolgreich ist. Ist sie erfolgreich, gilt die Gesamtauthentifizierung alserfolgreich und login() kehrt sofort zurück. Schlägt die Anmeldung mit diesem Modul fehl, werdennachgeordnete Login-Module auch noch ausgeführt.

optional Die Authentifizierung mit dem Modul braucht nicht zwingend erfolgreich sein, damit dieGesamtauthentifizierung erfolgreich ist. Nachgeordnete Login-Module werden in jedem Fall nochausgeführt, unabhängig davon, ob die Anmeldung mit diesem Modul fehlschlägt.

48


JAAS AutorisierungBasiert auf den bei der Authentifizierung zugewiesenenPrincipals.

Beispiele:

Permission zum Lesen und Schreiben des Verzeichnisses "/home/Alice„ fürCode der als X500Principal mit "Alice„ ausgeführt wird.grant principal javax.security.auth.x500.X500Principal"Alice" {

permission java.io.FilePermission "/home/Alice", "read, write";

};

Nachdem sich ein Benutzer authentifiziert hat, bietet JAAS Zugriffsschutz basierend auf den bei derAuthentifizierung zugewiesenen Principals des Benutzers. In JAAS kann in der Politik-Dateispezifiziert werden, auf welche Ressourcen welche Principals zugreifen können. Im Beispiel darf derCode im Verzeichnis /home/Alice lesen und schreiben, wenn der Code von einem Principal der Klassejavax.security.auth.x500.X500Principal ausgeführt wird und die getName()-Methode „Alice“zurückgibt.

49


Permission zum Lesen und Schreiben in "/tmp/games" für Code von"www.games.com", signiert von "Duke" und ausgeführt von "Alice„.grant codebase "http://www.games.com", signedBy "Duke", principal javax.security.auth.x500.X500Principal

"Alice"{

permission java.io.FilePermission "/tmp/games", "read, write";

};

Kombination aus Code-basiertem und Benutzer-basiertem Zugriffsschutz.

Ein zweites Beispiel zeigt diese Folie.

50


Durchsetzen der JAAS-Politik

LoginModule

PrincipalPrincipalPrincipal

Subjekt

Authentifizierung

Subjekt

SecurityManager

Aktion

Politik

Autorisierung

Zunächst erfolgt eine Authentifizierung, d. h. ein Subjekt wird durch den Login-Prozess mit Principalsversehen. Der Security Manager prüft dann anhand der Principals des Subjektes und der Politik, ob dasSubjekt eine spezifische Aktion durchführen darf.

51


Aktion als bestimmtes Subjekt ausführen mit doAs()-Methode der Klasse Subject.

public static Object doAs(

final Subject subject,

final java.security.PrivilegedAction action)

Security Manager (bzw. Access Controller) prüft, ob diePolitik die Berechtigungen für die Aktion für einen derPrincipals des Subjekts gibt.

Sollen Aktionen unter einem bestimmten Subjekt ausgeführt werden, gibt es die Methode doAs() derKlasse Subject. Der SecurityManager prüft dann, ob die Policy die benötigten Berechtigungen für einender Principals des Subjects gibt.

52


Beispiel: Benutzer hat sich vorher authentifiziert.

Subject subject = loginContext.getSubject();

try { subject.doAs(subject,new ExampleAction());} catch(PrivilegedActionException e) {...}

mit

class ExampleActionimplements java.security.PrivilegedAction { }

6.3 Zugriffsschutz in Java - inf.fu-berlin.de · 1 6.3 Zugriffsschutz in Java Zusätzlich zum...

Documents

Transcript of 6.3 Zugriffsschutz in Java - inf.fu-berlin.de · 1 6.3 Zugriffsschutz in Java Zusätzlich zum...