6.3 Zugriffsschutz in Java

Transkript

1 Zusätzlich zum Schutz durch das Betriebssystem gewünschter Zugriff gemäß Politik und Klasse erlaubter Zugriff gemäß Benutzer-Privilegien und Schutzstatus erlaubter Zugriff JVM BS Die Java Sicherheitspolitik gilt zusätzlich zu den Sicherheitsmechanismen des Betriebssystems auf 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, die Berechtigung zum Lesen der Passwort-Datei nicht besitzt, wird die Java-Anwendung nicht die Datei lesen können. Die globale Zugriffsschutzstrategie ist der Schnitt der Strategie für die Java-Anwendung und der Strategie des Betriebssystems. 1

2 Java-Spracheigenschaften erhöhen Sicherheit keine Pointer-Arithmetik, daher keine ungültigen Speicherzugriffe 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 von Variablenwerten oder Überschreiben von Methoden Execeptions ermöglichen definierte und kontrollierte Programmabbrüche Java wurde mit dem Ziel entwickelt, einfach nutzbar zu sein. Die Hoffnung war, dass dies die Fehler von Programmieren verglichen mit anderen Programmiersprachen wie C oder C++ minimiert und somit die Sicherheit der Programme erhöht wird. Die Sicherheit in Java wird durch einige Eigenschaften erhöht: Java besitzt, anders als C oder C++, keine Pointer, so dass keine ungültigen Speicherzugriffe möglich sind. Java besitzt ein automatisches Speichermanagement, Garbage Collection, ein automatisches Prüfen von String- und Arraylä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 und kontrollierte Programmabbrüche. 2

3 Sichtbarkeit private: nur Code der Klasse default (package): Code der Klasse oder selbes Paket protected: Code der Klasse, selbes Paket oder Subklasse public: von jeder anderen Klasse Beurteilung: schützt Code vor Code statisch, ohne dynamische Prüfungen unterstützt least-priveledge-prinzip fö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 die Entität definiert ist. default (or package): Die Entität kann von Code aufgerufen werden, der innerhalb der Klasse der 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 der Entität enthalten ist, von Klassen desselben Pakets oder von einer Subklasse. public: Auf die Entität kann von jeder anderen Klasse aus zugegriffen werden. 3

4 Sicherheitsmechanismen der JVM Class File Verifier Stellt 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 stellen sicher, dass nur berechtigter Java Bytecode ausgeführt wird. Die Überprüfung der Binärdaten erfolgt in vier Schritten, von denen im ersten die Einhaltung des im Sprachstandard vorgegebenen Formats für Java-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 Klasse geprü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 des Bytecode 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ählt der Gebrauch der Parameter, die in richtiger Anzahl und korrektem Datentyp einem Aufruf folgen müssen. In Schritt 4 werden alle Verweise auf andere Klassen sowie auf Methoden und Attribute anderer Klassen verfolgt und überprüft. 4

5 Class Loader definiert lokalen Namensraum, der gefährlichen Code von der Beeinflussung korrekten und sicheren Codes abhält. Jeder Class Loader hat einen eigenen Namensraum (verhindert das Laden mehrerer Klassen mit demselben Namen). Namensräume sind Schutzschild zwischen Klassen unterschiedlicher 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 benutzt werden kann, gefährlichen Code von der Beeinflussung korrekten und sicheren Codes abzuhalten. Ein Namespace 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 einen Namespace geladen wird, ist es danach unmöglich eine weitere Klasse mit dem Namen Auto in diesen Namespace 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 Loadern geladen werden). Namespaces legen eine Art Schutzschild zwischen Klassen unterschiedlicher Namespaces: Klassen in identischen Namespaces können über die gewohnten Möglichkeiten miteinander kommunizieren, z.b. über mit dem Schlüsselwort public definierte Methoden. Sobald sich zwei Klassen aber in unterschiedlichen Namespaces befinden, also von unterschiedlichen Class Loadern geladen wurden, ist es für diese nicht einmal möglich, die Existenz der jeweils anderen festzustellen, solange der Programmierer dies nicht explizit ermöglicht. 5

6 Class Loader bilden eine Hierarchie (seit JDK1.2). Bootstrap Class Loader ist verantwortlich für das Laden der Core-Klassen der JAVA API. Werden als trusted angesehen. Benutzerdefinierte Class Loader laden restliche Klassen (z.b. der ausgeführten Applikation) Bootsrap Class 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 an der Spitze. Dieser Class Loader ist nur für das Laden der Klassen der Core-Java API zuständig. Für das Laden anderer Klassen, wie z.b. die Klassen der ausgeführten Applikation, sind seit Version 1.2 benutzerdefinierte Class Loader verantwortlich. 6

7 Vorgang 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 1 hindurchgereicht. Wenn der Bootstrap Class Loader die Klasse K nicht hat, so versucht der Class Loader N die Klasse zu laden.... Bootsrap Class Loader Class Loader N Class Loader 1 Möchte eine Applikation eine Klasse laden, so gibt der erste Class Loader die Anfrage an seinen Vaterknoten weiter, der selbst die Anfrage wieder an seinen Vaterknoten weiterleitet. Der letzte Knoten in 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, der ebenfalls 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 zu laden. 7

8 Ladevorgang 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 zum Bootstrap Class Loader, der zwar das Paket java.lang, aber die Klasse nicht findet. Alle anderen Class Loader der Hierarchie finden die Klasse auch nicht, so dass java.lang.virus vom Class Loader des Angreifers geladen wird. Frage: Kann java.lang.virus nun auf die Klassen (z.b. protected) im Paket java.lang zugreifen? Nein, da die Pakete java.lang von verschiedenen Class Loadern geladen wurden (und somit in verschiedenen runtime packages sind). Der Class Loader verhindert das Verändern von trusted class libraries. Trusted class libraries sind die Pakete, die von der Java Virtual Machine als definitiv sicher angesehen werden. Dazu gehören die Klassen 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 Class Loader nach oben geleitet. Dieser würde feststellen, dass das Paket java.lang zur Java API gehört und die Referenz auf diese Klasse zurückgeben. Betrachten wir ein zweites Beispiel. Angenommen ein Programm möchte die Datei java.lang.virus laden, die die Virtual Machine angreifen soll. Analog zum ersten Beispiel würde auch diese Anfrage bis ganz nach oben delegiert werden, der Bootstrap CL würde feststellen, dass er zwar das Paket java.lang kennt, 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 im Paket java.lang liegt könnte man jetzt davon ausgehen, dass diese die gleichen Rechte hat, wie jede Klasse in diesem Paket, beispielsweise auf mit dem Schlüsselwort protected geschützte Methoden und Attribute zuzugreifen. Dies ist aber nicht möglich, da die java.lang API Pakete von einem anderen Class Loader geladen wurden, als die java.lang.virus Klasse. Hier kommt der Begriff des runtime packages ins Spiel, der bedeutet, dass sich zwei (oder mehrere) Klassen nur dann im gleichen runtime package befinden, 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 im gleichen runtime package befinden müssen ist es der hier beispielhaft beschriebenen java.lang.virus Klasse also nicht möglich, die java.lang Klassen der API zu beeinflussen. 8

9 Security Manager (und Access Controler in Java 2) Zugriffe auf Ressourcen werden vom Security Manager der 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 und Betriebssystem-Kommandos Der Zugriff zu sicherheitskritischen Ressourcen läuft über die Java Virtual Machine und wird vorher durch den Security Manager geprüft. Der Security Manager schränkt die Aktionen von nicht vertrauenswürdigem Code auf ein Minimum ein. Die Operationen, die als gefährlich eingeschätzt werden 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 9

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 eine abstrakte Klasse. Benutzer mussten eigenen Security Manager schreiben und von der Klasse java.lang.securitymanager ableiten. Der Sicherheits-Manager ist ein Objekt, das für jede kritische Operation eine Methode zur Verfügung stellt, 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 der Java API immer aufgerufen, bevor eine Datei gelöscht wird. Diese Methode muss überprüfen, ob die als Parameter angegebene Datei gelöscht werden darf und wenn dies nicht der Fall ist, eine Exception erzeugen, so dass die Operation abgebrochen wird. 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. Sobald eine Applikation dann den Security Manager instantiiert und installiert kümmert sich der Security Manager um die Einhaltung der Sicherheitsrichtlinien, die durch die check-methoden definiert wurden. 10

11 FileInputStream fis = new FileInputStream("Textdatei.txt"); Erzeugen des FileInputStream Objects -> Security Manager muss um Erlaubnis gefragt werden Ist ein Security Manager installiert YES NO Recht wird gewährt checkread() wird aufgerufen Lesen erlaubt? YES checkread() returns NO checkread() throws Exception read wird ausgeführt Dieses Diagramm zeigt an einem Beispiel die bei der Ausführung einer sicherheitskritischen Operation nötigen Schritte. Wenn keine Security Manager installiert ist, wird der Zugriff sofort gewährt. Gibt es einen Security Manager, wird die entsprechende check()-methode des installierten Security Managers aufgerufen und der Zugriff von diesem überprüft. 11

12 Seit JDK 1.2 ist java.lang.securitymanager eine konkrete Klasse, die eine Default-Implementierung des Security Managers darstellt. Installieren des default Security Managers über die Kommandozeile 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 Aufruf folgender Option über die Kommandozeile installiert werden: -Djava.security.manager. Benutzerdefinierte Sicherheitspolitiken werden in einem ASCII-File, genannt Policy File, definiert und nicht mehr in Java-Code implementiert (d.h. in der abgeleiteten Klasse des abstrakten SecurityManagers). 12

13 Zugriff auf Systemressourcen läuft weiterhin über Security Manager, dieser implementiert aber nicht mehr die Zugriffsregeln. Security Manager reicht Anfrage an den Access Controller weiter. Access Controler verwendet das Poilcy File zur Zugriffsentscheidung. Beim Zugriff auf Systemressourcen wird in Java 2 zwar weiterhin der Security Manager konsultiert, die Zugriffsregeln allerdings sind nicht mehr in ihm implementiert, sondern werden an den Access Controller weitergeleitet. Wenn also eine check-methode des default Security Managers aufgerufen wird, so wird der Request an die Klasse AccessControler weitergeleitet. Der Access Controller verwendet die Information des Policy Files, um zu entscheiden, ob die Aktion erlaubt werden soll oder nicht. 13

14 Sandboxmodell JDK 1.0 Sandbox ist eine beschränkte Umgebung für nicht vertrauenswürdigen Code Lokaler Code ist vertrauenswürdig und hat vollen Zugriff auf Systemressourcen. Code aus dem Internet (Applet) ist nicht vertrauenswürdig. Security Manager bestimmt die erlaubten Zugriffe. Das originale Java Sicherheitsmodell, bekannt als Sandbox" Modell, stellt eine sehr beschränkte Umgebung zur Verfügung, in der nicht vertrauenswürdiger Code ausgeführt werden kann. Im Sandbox-Modell ist lokaler Code vertrauenswürdig und hat vollen Zugriff zu den 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 der Sandbox zugreifen. Der Security Manager ist verantwortlich, zu bestimmen, welche Ressourcenzugriffe erlaubt sind. 14

15 In der Sandbox sind folgende Aktionen nicht möglich. Lesen oder Schreiben auf der lokalen Platte Eine Netzwerkverbindung zu einem Rechner aufbauen außer dem Rechner, von dem das Applet geladen wurde. Einen neuen Prozess starten Eine neue DLL laden Aktionen, die Code in der Sandbox nicht möglich sind, zeigt die Folie. 15

16 Signierung von Applets Digital signierte Applets werden wie lokaler Code behandelt. Öffentlicher Schlüssel zum Verifizieren muss vertrauenswürdig sein. Unsignierte Applets laufen weiterhin in der Sandbox Sandboxmodell JDK 1.1 JDK 1.1 führte signierte Applets ein. Ein digital signiertes Applet wird wie lokaler Code behandelt, mit vollen Zugriff auf die Ressourcen, wenn der öffentliche Schlüssel zum Verifizieren der Signatur vertrauenswürdig ist. Unsignierte Applets werden weiterhin in der Sanbox ausgeführt. Signierte Applets werden mit ihrer Signatur in signierten JAR (Java ARchive) Dateien geliefert. 16

17 Sandboxmodell JDK 1.2 Code wird mit einer Sicherheitspolitik assoziert. Sicherheitspolitik enthält eine Menge von Permissions (z.b. Erlaubnis zum Zugriff auf Systemressource oder Verbindung zu einem Rechner bzw. Port). Sicherheitspolitik wird vom Benutzer oder Administrator definiert. JDK 1.2 führt mehrere Erweiterungen bzgl. JDK 1.1. ein: Erstens, der gesamte Code, egal ob local oder remote, kann nun mit einer Sicherheitspolitik (security policy) assoziiert werden. Die Sicherheitspolitik definiert eine Menge von Permissions und muss bei einem Benutzer oder dem Systemadministrator konfiguriert werden. Jede Permission spezifiziert einen erlaubten Zugriff auf eine bestimmte Ressource, z.b. Lese- und Schreibzugriff auf eine Datei oder ein Verzeichnis oder die Erlaubnis sich zu einem bestimmten Host oder Port zu verbinden. 17

18 Sandboxmodell JDK 1.2 Code ist in Domänen (domains) aufgeteilt. Domäne ist eine Menge von Klassen, deren Instanzen die gleichen Rechte haben. Extreme von Domänen: voller Zugriff und Sandbox-Konfiguration. Die Laufzeitumgebung organisiert den Code in Domänen (domains), jede betrifft eine Menge von Klassen, deren Instanzen die gleichen Rechte gewährleistet werden. Eine Domäne kann wie eine Sandbox konfiguriert sein, so dass Applets weiterhin in einer beschränkten Umgebung ausgeführt werden können. Der linke Pfeil in der Abbildung entspricht einer Domäne, in der dem Code vollen Zugriff gewährt wird. Der Pfeil auf der rechten Seite repräsentiert das andere Extrem. Diese Domäne entspricht der Sandbox. Die dazwischen liegenden Domänen haben weniger Zugriffsrechte als der volle Zugriff aber mehr als die Sandbox. 18

19 Wenn Klassen durch einen Class Loader in die JVM geladen werden, wird jeder Klasse genau eine Domäne zugeordnet. Threads, die mehrere Domänen umfassen, haben den Schnitt der Permissions dieser Domänen. a.class b.class c.class d.class Dom A Dom B Permissions Permissions Klasse Domain Permission Eine Domäne umfasst eine Menge von Klassen, deren Instanzen dieselbe Menge von Permissions haben. 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 ablaufen oder können mehrere Domänen umfassen. In diesem Fall gilt, dass die Menge der Permissions für den Thread der Schnitt der Permissions aller Domänen ist, die der Thread benutzt. 19

20 Permissions repräsentieren den Zugriff auf Systemressourcen. Abstrakte Klasse java.security.permission Neue Permissions erweitern diese Klasse. Actions sind die erlaubten Aktionen auf einem Objekt, z.b. perm1 = new FilePermission(p1,"read,write"); perm2 = new FilePermission(p2,"write,read"); Die Permission-Klassen repräsentieren den Zugriff zu Systemressourcen. Die java.security.permission Klasse 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 der folgende Code: perm = new java.io.filepermission("/tmp/abc", "read"). Neue Permissions können von der Permission-Klasse oder Unterklassen abgeleitet werden. Die abstrakte Methode implies muss von neuen 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 Permissions enthalten eine Liste von Actions die sagt, welche Aktionen für das Objekt erlaubt sind. In einem java.io.filepermission Objekt könnte die Aktionsliste beispielsweise aus read, write bestehen. 20

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 den Zugriff auf eine Datei oder ein Verzeichnis (spezifiziert im Parameter path). Die Aktionen für den Parameter actions sind read, write, delete, und execute. Die Folie zeigt einige Beispiele ihrer Anwendung. Das Beispiel FilePermission p = new FilePermission("/home/gong/", "read"); gibt beispielsweise die Permission zum Lesen des Verzeichnisses (d.h. das Auflisten der darin enthaltenen Dateien), jedoch nicht das Leserecht auf den Dateien selbst. Um auch die Dateien des Verzeichnisses lesen zu können, muss man dies explizit durch den Dateinamen angeben oder durch * (alle Dateien im Verzeichnis) bzw. - (alle Dateien im Verzeichnis und allen Unterverzeichnissen). Mit <<ALL FILES>> wird die Permission auf allen Dateien des Systems gewährt. 21

22 Beispiel: java.lang.runtimepermission Permission braucht nicht unbedingt keine Aktionen. createclassloader setcontextclassloader createsecuritymanager modifythread modifythreadgroup readfiledescriptor... getclassloader setsecuritymanager exitvm stopthread getprotectiondomain writefiledescriptor Die java.lang.runtimepermission ist ein Beispiel einer Permission, die keine Aktionen erfordert. Das Zielobjekt der RuntimePermission kann als String repräsentiert werden ohne das eine Aktion mit diesem Zielobjekt verbunden wäre. RuntimePermission("exitVM") soezifiziert zum Beispiel die Permission die Java Virtual Machine zu verlassen. 22

23 Die implies-methode vereinfacht den Vergleich von Permissions und gibt einen Überblick über die Mä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-methode implementieren. Betrachten wir zum Beispiel java.io.filepermission("/tmp/*", "read"), so impliziert diese Permission java.io.filepermission("/tmp/a.txt", "read"). 23

24 Implikation ist nicht immer offensichtlich. Wenn Applet die Permission zum Schreiben auf dem Dateisystem hat, kann es die JVM Runtime-Umgebung austauschen, in der es dann alle Permissions hat. Wenn ein Applet die RuntimePermission zum Erzeugen von Class Loadern hat, hat es auch viele Permissions des Class Loaders. Gefahren der Permissions sind unter PermRisks beschrieben. 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 Dateisystem hat. Dies erlaubt dem Applet u.a. die JVM Runtime-Umgebung zu ersetzen. Damit hat dann das Applet alle 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 Loaders gewährt. Andere gefährliche Permissions und ihre Risiken sind unter beschrieben. 24

25 java.lang.runtime Permission createclassloader getclassloader Was erlaubt die Permission Erzeugt einen Class Loader Erhalten eines Class Loaders Risiko Anwendungen können ihren eigenen Class Loader erzeugen, mit dem sie ihre eigenen Klassen ins System laden. Diese Klassen können in jede Domäne gepackt werden, womit den Klassen die Domänen-Permissions gewährt werden. Dies erlaubt einem Angreifer den Class Loader einer Klasse zu erhalten. Jedoch können auch alle anderen Klassen geladen werden, auf die der Angreifer keinen Zugriff hat. Diese und die nächste Folie zeigen ein Beispiel für die Risiken, die sich durch die Zuordnung der RuntimePermission ergeben können. 25

26 java.lang.runtimep ermission setsecuritymanager exitvm Was erlaubt die Permission Setzt einen Security Manager Anhalten der JVM Risiko Dies erlaubt Code den Securiyt Manager gegen einen weniger restriktiven Security Manager auszutauschen, um die Zugriffüberprüfungen des ursprünglichen Security Managers zu umgehen. Erlaubt Denial-of-Service-Attacken..und viele weitere Gefahren! 26

27 Policy-Objekt repräsentiert die Politik einer Java Anwendung. Politik ist in einer oder mehreren Politik-Konfigurationsdateien 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 ein Applet (oder eine Anwendung, die unter einem Security Manager läuft) geschützte Aktionen (wie das Lesen oder Schreiben von Dateien) durchführen kann, müssen ihm die Permissions für diese Aktion gewährt werden. Eine Ausnahme ist, das Code immer das Recht hat, Dateien von seiner CodeSource zu lesen. 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/sysadmin die Erlaubnis zum Lesen des Verzeichnisses /tmp/abc gegeben wird. 27

28 Politik-Dateien können im Textedtior oder mit dem Tool policytool erstellt werden. Systemweite Standard-Politik unter java.home\lib\security\java.policy (Windows) (Optionale) Benutzerspezifische Politik unter user.home\.java.policy (Windows) Politik-Objekt wird mit Systempolitik initialisiert und die benutzerspezifische 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 in java.home/lib/security/java.policy (Solaris) bzw. java.home\lib\security\java.policy (Windows) und eine optionale benutzerspezifische Politik-Datei unter user.home/.java.policy (Solaris) bzw. user.home\.java.policy (Windows). Wenn das Politik-Objekt initialisiert wird, wird zunächst die systemweite Politik geladen und dann die benutzerspezifische zugefügt. 28

29 Policy-Datei-Format enthält einen Keystore-Eintrag und eine Liste von grant -Einträgen. Keystore ist Datenbank für private Schlüssel mit Zertifikaten für die öffentlichen Schlüssel (siehe Kryptographie ) Keystore benutzt öffentliche Schlüssel der in den grant -Einträgen angegebenen Signierenden. Syntax: keystore "some_keystore_url", "keystore_type"; keystore_type gibt das Speicher- und Datenformat des Keystores an. Eine Policy-Konfigurationsdatei kann einen keystore -Eintrag und null oder mehr grant -Einträge enthalten. Ein Keystore ist eine Datenbank privater Schlüssel mit entsprechenden X.509 Zertifikaten für die zugehörigen öffentlichen Schlüssel. Der Keystore wird dazu benutzt, die öffentlichen Schlüssel derjenigen 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. 29

30 Ein grant -Eintrag gibt eine Menge von Permissions an spezifizierten Code. 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 der codebase): grant { permission java.io.filepermission ".tmp", "read"; }; Jeder grant -Eintrag besteht aus einem CodeSource und den gewährten Permissions. Die folgenden Folien zeigen einige Beispiele. 30

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 von grant codebase " "Li" { permission java.io.filepermission "/tmp/*", "read"; permission java.io.socketpermission "*", "connect"; }; 31

32 Zwei Permissions für Code signiert von Li und Roland, nur wenn der Bytecode 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"; }; 32

33 Access Controller überprüft bei einem Zugriff, ob die erforderlichen Permissions existieren. Geschieht mittels Stack Inspection. Bytecode Identity Code Source Signers Java Runtime Policy Access Controller " Stack Inspection Die Überprüfung auf ausreichende Rechte wird seit JDK1.2 von der Klasse AccessController bewerkstelligt. Dabei werden Maßnahmen ergriffen, um Missbrauch von Code mit mehr Rechten durch ein Programm mit wenigen Rechten zu verhindern. Dies geschieht durch Überprüfung aller Rufer am Call Stack. Dieser Mechanismus wird als Stack Inspection bezeichnet. 33

34 Stack Inspection Überprüft ob alle Aufrufer in der Ruferkette die entsprechenden 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üft ob die Permission vorhanden ist. Bei einer Stack Inspection wird geprüft, ob alle Methoden in der Ruferkette die entsprechenden Permissions besitzen. Nur wenn alle Rufer am Call Stack die entsprechende Permission besitzen, darf eine Aktion ausgeführt werden. Betrachten wir als Beispiel eine Klasse A, die eine Methode der Klasse B aufruft, die wiederum eine Methode der Klasse C aufruft, welche schließlich eine Methode der Klasse java.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 alle Klassen ü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. 34

35 Access Controller überprüft der Reihe nach, ob die Aufrufer auf dem Stack die geforderte Permission haben. Überprüft die Permission mit der Methode implies() des ProtectionDomain-Objekts. public boolean implies(permission permission) Hat einer der Aufrufer nicht die benötigte Permission, so gibt der Access Controller eine AccessControlException zurück und der 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 Klasse ProtectionDomain deklariert. Als einzigen Parameter erwartet diese Methode ein Objekt vom Typ Permission. Diese Methode überprüft ob eine Permission in der ProtectionDomain enthalten ist. Ist das der Fall wird true zurückgegeben, andernfalls false. Stellt der AccessController während der Stack Inspection 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 die Ressource kann nicht ausgeführt werden. Die Operation bricht ihrerseits mit einer SecurityException ab. 35

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, Message Authentication Code Java Authentication and Authorization Service (JAAS) Enthält Pakte zur Authentifizierung und Zugriffskontrolle von Benutzern. 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 weitere Sicherheitsaspekte: -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 zur Authentifizierung und Zugriffskontrolle von Benutzern. -Die Java Secure Socket Extension (JSSE) ist eine Menge von Paketen die eine sichere Internet-Kommunikation ermöglichen. Implementiert eine Java Version von Secure Sockets Layer (SSL) und Transport Layer Security (TLS) Protokollen. Enthält Funktionen für die Datenverschlüsselung, Server-Authentifizierung, Nachrichtenintegrität und optional Client- Authentifizierung. 36

37 JAAS ist eine Ergänzung zur Java 2 SDK Sicherheitsarchitektur 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 Zugriffsentscheidung basiert auf der Frage: Wer führt den Code aus? JAAS Autorisierung erweitert die Java Sicherheitsarchitekur. Die Java Sicherheitsarchitektur benutzt eine Security policy, um zu spezifizieren, welche Zugriffsrechte einem Code zugewiesen werden. Diese Architektur ist Code-zentriert, d.h. die Permissions wurden basierend auf den Eigenschaften des Codes erteilt: woher kommt der Code und wer hat ihn signiert. Mit der Integration von JAAS in das Java 2 SDK ist es nun möglich benutzerbasierte Permissions zu definieren. Somit basiert der Zugriffsschutz nun nicht nur auf dem Code der ausgeführt wird, sondern auch darauf, wer den Code ausführt. 37

38 Java 2 Sicherheit ist Code-zentriert CodeSource Code Signierende Permissions Das Java Standardsicherheitsmodell ist Code-zentriert. In der Security Policy werden Permissions aufgrund der Herkunft des Codes und des Signierenden des Codes vergeben. 38

39 Java 2 und JAAS CodeSource Code Signierende Benutzer Permissions Mit JAAS kann in der Security Policy auch spezifiziert werden, an welchem Benutzer die Permission gebunden ist. 39

40 JAAS Authentifizierung Weist einem Benutzer, der eine Anwendung ausführt, eine authentifizierte Benutzererkennung (Principal) zu. Anwendungen sind unabhängig vom Authentifizierungsservice Anwendung LoginContext LoginModule Modulkonfiguration Kerberos Smartcard Biometrie 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 vom Authentifizierungsservice zu bleiben. Es kann beispielsweise eine Authentifizierung über Kerberos, Smartcards, Biometrie etc. erfolgen. Die Schnittstelle zwischen JAAS und einem Programm, das JAAS benutzt, ist die Klasse LoginContext aus dem Paket javax.security.auth.login. 40

41 LoginContext beschreibt den Namen des Kontextes, der die Login- Modulkonfiguration spezifiziert (Modulkonfiguration steht in einer Datei). einen CallbackHandler, der Benutzerinteraktionen für das Modul durchführt (z.b. Abfrage eines Passworts) Da Benutzer-Abfragen mit der Anwendung variieren, sind sie nicht direkt im Modul kodiert, sondern getrennt im CallbackHandler. Ein LoginContext benötigt zwei Informationen: 1. Den Namen des Kontextes. Dieser Name identifiziert die Login-Modulkonfiguration, die für den Kontext verwendet werden soll. Diese Modulkonfiguration steht in einer Datei. 2. Ein Exemplar der Klasse CallbackHandler. Dieses Objekt dient dazu, Benutzerinteraktionen durchzuführen, die die Module benötigen. Eine solche Interaktion könnte die Abfrage eines Passworts sein. Da die Form solcher Abfragen stark von der Anwendung abhängt (z. B. Kommandozeile oder grafischer Dialog), sind sie nicht in den Modulen selbst kodiert, sondern werden über einen CallbackHandler abgewickelt. 41

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 Authentifizierungsmodul eingetragen wird. 2. Es muss eine Unterklasse von CallbackHandler erstellt werden, in der die Benutzerinteraktion durchgeführt wird. 3. Es muss ein LoginContext erzeugt werden, mit dessen Methode login() das eigentliche Login durchgeführt werden kann. 42

43 Beispiel: Modulkonfiguration Demo Demo { com.sun.security.auth.module.unixloginmodule required 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 keinen CallbackHandler), da direkt die Betriebssystem-Benutzererkennung benutzt wird. Das Modul com.sun.security.auth.module.unixloginmodule ist ein Login-Modul, das standardmäßig bei J2SE dabei ist und Principals für Unix-Benutzer-IDs ausstellt, unter der das Programm ausgeführt wird. Dieses Modul erfordert keine Benutzerinteraktion und somit auch keinen speziellen CallbackHandler. Die Principals werden automatisch aus der Betriebssystem-Benutzerkennung erstellt. 43

44 Weitere Standard-Module sind JndiLoginModule für eine Authentifizierung gegenüber einem LDAP-Verzeichnis. Krb5LoginModule für die Anmeldung an einem Kerberos-System. KeyStoreLoginModule für eine Authentifizierung gegenü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. 44

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(); 45

46 JAAS erlaubt mehrere Login-Module in einer Konfiguration Demo { com.sun.security.auth.module.unixloginmodu le required debug=false; demo.myloginmodule optional debug=false; }; Tags in Konfiguration entscheiden, wie sich die gesamte Authentifizierung bzgl. Der Modul-Authentifizierungen verhält. Bei JAAS können Login-Module auch kaskadiert, d. h. nacheinander ausgeführt werden. Im Beispiel der Folie wird zunächst eine Anmeldung mit dem UnixLoginModule und danach mit MyLoginModule durchgefü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 erfolgreich durchlaufen 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 gesamten Kette unterschieden. Bei JAAS kann für jedes einzelne Login-Modul konfiguriert werden, ob die Principals nur dann gewährt werden, wenn die gesamte Kette erfolgreich war, oder ob es bereits genügt, wenn das Modul selbst abgeschlossen wurde. 46

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 Tag required requisite sufficient optional Erfolg zwingend ja ja nein nein Ausführung folgender Module immer nur bei Erfolg nur bei Misserfolg immer 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 nachfolgende Module überhaupt noch zur Ausführung kommen sollen. Die Tags sind im Einzelnen: required Die Authentifizierung des Moduls muss erfolgreich sein, damit die Gesamtauthentifizierung erfolgreich 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 Gesamtauthentifizierung erfolgreich ist. Falls die Anmeldung mit diesem Modul fehlschlägt, ist auch die Gesamtauthentifizierung fehlgeschlagen und login() kehrt sofort zurück. Ist die Anmeldung mit diesem Modul dagegen erfolgreich, werden nachgeordnete Login-Module auch noch ausgeführt. sufficient Die Authentifizierung mit dem Modul braucht nicht zwingend erfolgreich sein, damit die Gesamtauthentifizierung erfolgreich ist. Ist sie erfolgreich, gilt die Gesamtauthentifizierung als erfolgreich und login() kehrt sofort zurück. Schlägt die Anmeldung mit diesem Modul fehl, werden nachgeordnete Login-Module auch noch ausgeführt. optional Die Authentifizierung mit dem Modul braucht nicht zwingend erfolgreich sein, damit die Gesamtauthentifizierung erfolgreich ist. Nachgeordnete Login-Module werden in jedem Fall noch ausgeführt, unabhängig davon, ob die Anmeldung mit diesem Modul fehlschlägt. 47

48 JAAS Autorisierung Basiert auf den bei der Authentifizierung zugewiesenen Principals. Beispiele: Permission zum Lesen und Schreiben des Verzeichnisses "/home/alice für Code 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 der Authentifizierung zugewiesenen Principals des Benutzers. In JAAS kann in der Politik-Datei spezifiziert werden, auf welche Ressourcen welche Principals zugreifen können. Im Beispiel darf der Code im Verzeichnis /home/alice lesen und schreiben, wenn der Code von einem Principal der Klasse javax.security.auth.x500.x500principal ausgeführt wird und die getname()-methode Alice zurückgibt. 48

49 Permission zum Lesen und Schreiben in "/tmp/games" für Code von " signiert von "Duke" und ausgeführt von "Alice. grant codebase " 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. 49

50 Durchsetzen der JAAS-Politik LoginModule Subjekt Aktion Subjekt Principal Principal Principal Authentifizierung SecurityManager Autorisierung Politik Zunächst erfolgt eine Authentifizierung, d. h. ein Subjekt wird durch den Login-Prozess mit Principals versehen. Der Security Manager prüft dann anhand der Principals des Subjektes und der Politik, ob das Subjekt eine spezifische Aktion durchführen darf. 50

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 die Politik die Berechtigungen für die Aktion für einen der Principals des Subjekts gibt. Sollen Aktionen unter einem bestimmten Subjekt ausgeführt werden, gibt es die Methode doas() der Klasse Subject. Der SecurityManager prüft dann, ob die Policy die benötigten Berechtigungen für einen der Principals des Subjects gibt. 51

52 Beispiel: Benutzer hat sich vorher authentifiziert. Subject subject = logincontext.getsubject(); try { subject.doas(subject,new ExampleAction()); } catch(privilegedactionexception e) {...} mit class ExampleAction implements java.security.privilegedaction { } 52