Java Security Manager Seminararbeit von Bodmer Martin, Ia00

Transkript

1 Java Security Manager Seminararbeit von Bodmer Martin, Ia00 Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: Prof. Dr. C. Nicola Windisch, 19. Juni 2003

2 Zusammenfassung Seite 1 Dieses Dokument gibt einen umfassenden Überblick über das Java Sicherheits-Model (java security model). Es zeigt unter anderem die Entwicklung von Java Security in den letzten Jahren und erläutert die einzelnen Komponenten und deren Zusammenspiel. Im Speziellen wird auf den Java Security Manager eingegangen und anhand eines Beispiels gezeigt, wie man einen eigenen Security Manager erstellen kann. Das Erstellen eines Policy-Files wird ebenfalls detailliert beschrieben.

3 Inhaltsverzeichnis Seite 2 Einleitung Entwicklung von Java Security JDK 1.0 Security - Das Sandkastenmodell JDK 1.1 Security - Alles oder nichts Java 2 Security - fine-grained security Java 2 Security im Detail Byte-Code Verifier ClassLoader CodeSource Permissions Protection Domains Policy Securtiy Manager AccessController Der keystore Der Security Manager im Einsatz Der eigene Security Manager Verwendung von Permissions Das dazugehörige Policy File Starten von Applets/Applikationen Applets Applikationen Neue Möglichkeiten und Gefahren Schlussfolgerung A. Anhang A1. Applikationsbeispiel Code A1.1. FileIO.java A1.2. PasswordSecurityManager.java A1.3. secure.policy A2. Bibliographie... 24

4 Seite 3 Einleitung Sicherheit gewann in den letzten Jahren immer mehr an Bedeutung bei der Softwareentwicklung. Dies, weil die globale Vernetzung von Rechnern in dieser Zeit rapide zugenommen hat und das Verlangen von Benutzern, wie auch von Entwicklern, nach sicherer Software gestiegen ist. SUN hat dieses Problem schon früh erkannt und bietet seit der Entwicklung von Java ein Sicherheitsmodell. Dieses war in den letzten Jahren einem steten Wandel unterzogen, um den neuen Sicherheitsanforderungen gerecht zu werden und um das Sicherheitsmodell zu verfeinern. Eine Kernkomponente des Java Security Modells ist der Security Manager und diesen wollen wir nun im folgenden genauer erläutern und dessen Einsatz an einem Beispiel zeigen.

5 Seite 4 1 Entwicklung von Java Security Man schaute schon bei der Entwicklung von Java darauf, aus den Fehlern anderer Programmiersprachen, wie C oder C++, zu lernen. Es wurden daher von Anfang an gewisse Sicherheitskonzepte eingeführt. Zum Beispiel kann man mit Java nicht direkt auf den Speicher zugreifen, sondern ihn nur via Referenzen ansprechen, Objekte und Methoden die als final deklariert wurden können nicht geändert werden, Arraygrenzen werden bei jedem Zugriff geprüft, Object casting ist beschränkt (Type safety!), Varaiblen können nicht verwendet werden bevor sie initialisiert sind, Garbage collection schaut dafür, dass nicht mehr verwendeter Speicher wieder freigegeben wird. Das Security Model von Java hat in den letzten paar Jahren eine erhebliche Veränderung erlebt. In den folgenden Kapiteln sollen nun kurz diese Entwicklungsstufen aufgezeigt werden. 1.1 JDK 1.0 Security - Das Sandkastenmodell Das JDK 1.0 (Java Development Kit) hatte ein sogenanntes Sandkasten Sicherheitsmodell (sandbox security model). Dieses Modell machte eine restriktive Trennung zwischen Java Applikationen und Applets. Alle Applikationen, da sie immer lokal geladen wurden, wurden durch das Security Model als vertrauenswürdig angeschaut und hatten daher uneingeschränkten Zugriff auf alle Ressourcen des JDK 1.0. Im Gegensatz dazu wurden alle Applets, da sie meistens über ein Netzwerk geladen wurden, als nicht vertrauenswürdig eingestuft und hatten dementsprechend relativ eng beschränkten Handlungsraum. Das Applet konnte nun in diesem kreierten Sandkasten arbeiten, ohne eine Sicherheitsrisiko für die JVM oder das darrunterliegende System darzustellen.

6 1.2 JDK 1.1 Security - Alles oder nichts Seite 5 Man sah schnell ein, dass das Sandbox-Model des JDK 1.0 zu restriktive ist und man suchte eine passende Lösung. Im JDK 1.1 wurden daher die sogenannten signierten Applets (signed applets) eingeführt. Ein signiertes Applet ist ein Applet verpackt in einem Java Archiv (JAR) und mit einem privaten Schlüssel (private key) signiert. Dieses Konzept ermöglichte nun einen Unterschied zwischen Applets, die von vertrauenswürdigen Quellen kamen und solchen die von nicht vertrauenswürdigen Quellen stammten. Vertrauenswürdige Applets hatten die gleichen Berechtigungen wie lokal geladene Applikationen Dieses Konzept war aber immer noch nicht zufriedenstellend, denn es erlaubte nur einem Applet den vollen Zugriff zu gewähren oder es in dem vorgegebenen Sandkasten laufen zu lassen. Zudem hatten Applikationen immer noch von Grund auf vollen Zugriff, obwohl es zum Teil wünschenswert wäre diese in einem Sandkasten laufen zu lassen, wenn man nicht weiss, woher die Applikation kommt.

7 Seite Java 2 Security - fine-grained security Der grosse Unterschied zwischen dem Java 2 Sicherheitsmodell und seinen Vorgängern ist, dass erstmals nicht nur zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code unterschieden werden kann, sondern es erlaubt, Code in verschiedene Sicherheitsstufen einzuteilen (fine-grained security), indem man dem Code definierte Einschränkungen bzw. Erlaubnisse (Permissions) zuweist. Einschränkungen können sowohl für Applets, wie auch für Applikationen definiert werden. Applikationen werden ohne angegebene Einschränkungen per Default als unrestricted angesehen und haben daher wie in JDK 1.2 vollen Zugriff auf die Ressourcen.

8 Seite 7 2 Java 2 Security im Detail Das Java 2 Sicherheitsmodell ist ein abgestimmtes Zusammenspiel verschiedenster Komponenten, die die Sicherheit gewährleisten sollen. In der untenstehenden Abbildung ist dieses Zusammenspiel dargestellt. Wir wollen nun in den folgenden Kapiteln die einzelnen Komponenten und deren Funktion betrachten. 2.1 Byte-Code Verifier Java Code muss nicht unbedingt von einem Java-Compiler stammen, er könnte zum Beispiel auch durch eine andere C++-Applikation erzeugt worden sein. Java Code wird auch oft über das Internet heruntergeladen und hier weiss man selten, wie dieser Code zustandgekommen ist. Um diesem Problem entgegenzuwirken, prüft der Byte-Code Verifier alle Klassendateien des Benutzers (user class files) ob die darin enthaltene Reihe von Byte-Code legal ist. Unter anderem untersucht der Byte-Code Verifier das Format der Klassendatei, d.h. es muss die richtige Länge haben, die korrekten magic numbers enthalten, keine operand stack overflows oder underflows besitzen und so weiter.

9 2.2 ClassLoader Seite 8 Der ClassLoader ist dafür zuständig, dass die richtigen Klassen in die Virutual Machine geladen werden. Zudem ist er auch für die verschiedenen Namensraume, die durch Packete (packages) kreiert werden, zur Laufzeit zuständig. Mit Namensräumen können verschiedene Objekte, die unter umständen den gleichen Namen besitzen, auseinandergehalten werden. 2.3 CodeSource Weil Java Code via Netzwerk heruntergeladen werden kann, ist es wichtig den Ursprung des Codes und dessen Autor zu kennen, um eine sichere Umgebung zu gewährleisten. Im Objekt java.security.codesource kann ein Java-Code komplett beschrieben werden. Das Objekt CodeSource enthält den Ursprung des Codes in Form einer URL und zudem eine Liste von Zertifikaten mit öffentlichen Schlüsseln, die zum privaten Schlüssel passen, mit dem der Code signiert wurde. Verschiedene Entscheide bezüglich Zugriffskontrolle basieren auf diesem Objekt. 2.4 Permissions Permissions bilden ein Kernpunkt des Java Sicherheitsmodells. Sie repräsentieren den Zugriff auf verschiedene Systemresourcen wie Dateien, Sockets, Systemeigenschaften, etc.. Zum Beispiel kann man damit einem Code Lese- und Schreib-Erlaubnis auf ein bestimmtes File gewähren. Eine Vielzahl der Permission-Klassen sind von der abstrakten Klasse java.security.permission abgeleitet, so zum Beispiel FilePermission, AWTPermission, etc.. Hier eine Liste der Möglichen Permissions: AllPermission AudioPermission AuthPermission AWTPermission FilePermission NetPermission PropertyPermission ReflectPermission RuntimePermission SecurityPermission SerializablePermission SocketPermission SQLPermission Für eine genauere Beschreibung der einzelnen Permissions, sowie bei welchen Methodenaufrufen welche Permission benötigt wird, verweise ich an dieser Stelle auf die Java j2sdk1.4.0 Dokumentation.

10 2.5 Protection Domains Seite 9 Es ist, wie vorher bereits erwähnt, möglich, Permissions einer Klasse zuzuweisen. Dies kann unter Umständen sehr kompliziert und aufwendig werden, wenn der Code aus vielen Klassen besteht. Es ist daher besser sich sogenannten Protection Domains zu bedienen, was einer Gruppierung von Klassen mit ähnlichen Anforderungen entspricht. Nun kann man einfach die nötigen Permissions diesen Protection Domains zuweisen. 2.6 Policy Die verschiedenen Zuweisungen von Permissions zu den jeweiligen Klassen wird policy (Politik, Taktik) genannt. Um die verschiedenen Permissions einer bestimmten Implementation zuweisen zu können werden sie in einer Policy-Datei gruppiert. Policy-Dateien können einfach in einem Text-Editor oder mit Hilfe des policytool, das im JDK enthalten ist, erstellt werden. Die allgemeine Syntax (dargestellt in BNF) für ein Policy-File sieht wie folgt aus: PolicyFile -> PolicyEntry PolicyEntry; PolicyFile PolicyEntry -> grant {PermissionEntry; grant SignerEntry {PermissionEntry grant CodebaseEntry {PermissionEntry grant PrincipalEntry {PermissionEntry grant SignerEntry, CodebaseEntry {PermissionEntry grant CodebaseEntry, SignerEntry {PermissionEntry grant SignerEntry, PrincipalEntry {PermissionEntry grant PrincipalEntry, SignerEntry {PermissionEntry grant CodebaseEntry, PrincipalEntry {PermissionEntry grant PrincipalEntry, CodebaseEntry {PermissionEntry grant SignerEntry, CodebaseEntry, PrincipalEntry {PermissionEntry grant CodebaseEntry, SignerEntry, PrincipalEntry {PermissionEntry grant SignerEntry, PrincipalEntry, CodebaseEntry {PermissionEntry grant CodebaseEntry, PrincipalEntry, SignerEntry {PermissionEntry grant PrincipalEntry, CodebaseEntry, SignerEntry {PermissionEntry grant PrincipalEntry, SignerEntry, CodebaseEntry {PermissionEntry keystore "url" SignerEntry -> signedby (a comma-separated list of strings) CodebaseEntry -> codebase (a string representation of a URL) PrincipalEntry -> OnePrincipal OnePrincipal, PrincipalEntry OnePrincipal -> principal [ principal_class_name ] "principal_name" (a principal) PermissionEntry -> OnePermission OnePermission PermissionEntry OnePermission -> permission permission_class_name [ "target_name" ] [, "action_list"] [, SignerEntry];

11 Seite 10 Default mässig besitzt Java zwei Policy-Files. Ein Systemumgreifendes Policy-File und ein Benutzer Policy-File. Das system policy-file befindet sich normalerweise in: {java.home/lib/security/java.policy {java.home\lib\security\java.policy (Solaris) (Windows) Das user policy-file befindet sich normalerweise in: {user.home/.java.policy (Solaris) {user.home\.java.policy (Windows) 2.7 Securtiy Manager Die Klasse java.lang.securitymanager ist der zentrale Punkt, was die Authorisierung von Zugriffen betrifft. Die Klasse enthält verschiedene Methoden (check-methods), die zur Überprüfung der Persmissions dienen. Es gibt zum Beispiel die Methode checkread(string file), welche den Zugriff auf ein bestimmtes File überprüft. Die Methode checkpermission(permission perm, Object context) überprüft, ob die benötigte Permission durch die policy gegeben ist oder nicht. Der Aufruf dieser Methode wird an den AccessController weitergeleitet, welcher dann die eigentliche Prüfung der benötigten Permission durchführt. Java bietet die Möglichkeit auch eigene Security Manager zu erstellen und zu verwenden. Dies erreicht man indem man die Klasse java.lang.securitymanager erweitert und die darin vorkommenden checkmethods überschreibt. Wichtig zu wissen ist, dass nur ein Security Manager geladen werden kann! Andernfalls könnte gefährlicher Code einen eigenen Security Manager einzusetzen versuchen, um so die Sicherheitsmechanismen von Java auszutricksen. 2.8 AccessController Die java.security.accesscontroller Klasse wird für drei Dinge benötigt: Zum entscheiden, ob der Zugriff auf kritische Systemressourcen, beruhend auf der aktuellen security-policy, erlaubt werden soll. Zum markieren von Code als privileged Um sich einen Schnappschuss des aktuellen calling context zu verschaffen, so dass Zugriffskontrollentscheide gemacht werden können. 2.9 Der keystore Der keystore ist eine passwortgeschützte Datenbank, welche private Schlüssel und Zertifikate enthält. Zertifikate, die sich in dieser Datenbank enthalten, werden als vertrauenswürdig betrachtet.

12 Seite 11 3 Der Security Manager im Einsatz Die Klassen der Java 2 Security befinden sich in erster Linie in folgenden Paketen: java.lang java.security java.security.cert java.security.interfaces java.security.spec Im folgenden wollen wir den Einsatz einiger Klassen der Java 2 Security betrachten und uns eine kleine Demo-Applikation zusammenstellen (Siehe Anhang für den vollständigen Code). 3.1 Der eigene Security Manager Eigene Security Manager können relativ leicht kreiert werden. Dazu muss die Klasse java.lang.securitymanager erweitert werden. public class PasswordSecurityManager extends SecurityManager{ Damit nun das Programm den eigenen Security Manager benutzt, gibt es zwei Möglichkeiten. Entweder man gibt in der Kommandozeile explizit den zu verwendenden Security Manager an, oder man setzt den Security Manger im Porgramm mit folgender Zeile: try{ System.setSecurityManager(new PasswordSecurityManager("pwd", buffy)); catch(securityexception se){ System.err.println("Security Manager already set!"); Es ist zu sagen, dass nur ein Security Manager pro Programm geladen werden kann. Das heisst, wenn wir nach dem Starten eines Programm mit der Kommandozeile java -Djava.security.manager myclass anschliessend versuchen einen neuen Security Manager mit der Methode System.setSecurityManager(new mysecuritymanager()); zu setzen, wird eine SecurityException geworfen. Dies macht Sinn, denn sonst könnte man leicht eine Attacke durchführen und seine eigenen Security Checks angeben.

13 3.2 Verwendung von Permissions Seite 12 Im selber kreierten Security Manager muss man nun noch die benötigten check-methoden der Superklasse java.lang.securitymanger überschreiben. Diese Methoden haben typische Namen die mit check beginnen, zum Beispiel checkread, checkwrite, etc.. Unten eine Beispiel- Implementierung der checkread-methode in der Klasse PasswordSecurityManager (siehe Anhang für den vollständigen Code). public void checkread(string filename) { //Mention file by name so don't get prompted for password //for everything the application loads to create itself System.out.println("checkRead for: "+filename); if((filename.equals("\\test\\text2.txt"))){ if(!accessok()){ System.out.println("checkRead: access not OK!"); super.checkread(filename); throw new SecurityException("No Way!"); else { System.out.println("checkRead: access OK!"); FilePermission perm = new FilePermission("/Test/text2.txt", "read"); checkpermission(perm); Wichtig im oben gezeigten Code sind die fettgedruckten Zeilen, die wir nun kurz anschauen und erläutern wollen. Mit der Zeile public void checkread(string filename) { überladen wir die Default-Implementierung des Standard Security Managers, bzw. der Klasse java.lang.securitymanager. Damit man einen Zugriff auf Systemressourcen machen kann muss man zuerst eine Referenz auf die gewünschte Permission kreieren. Dies bezweckt die folgende Zeile: FilePermission perm = new FilePermission("/Test/text2.txt", "read");

14 Seite 13 Wenn man die gewünschte Referenz auf eine Permission erzeugt hat, kann man nun den eigentlichen Check der Permission durchführen, was durch folgende Zeile erreicht wird: checkpermission(perm); Beim Aufruf der checkpermission-methode wird dieser an die Klasse AccessController weitergeleitet, der dann anhand der aktuellen Policy die eigentliche Prüfung des Zugriffs auf Systemressourcen vornimmt. 3.3 Das dazugehörige Policy File Bis jetzt haben wir im eigenen Security Manager nur Referenzen auf Permissions erzeugt. Die eigentlichen Permission werden jedoch im Policy-File angegeben. Für unser kleines Demo-Programm brauchen zwei FilePermissions, eine zum schreiben in text.txt und eine zweite zum lesen aus text2.txt, und eine PropertyPermission um die SystemProperty "os.name" zu erhalten. Unser Policy-File (Name: secure.policy) würde dann wie folgt aussehen: grant codebase "file:/c:/test/classes/-" { permission java.io.filepermission "/Test/text.txt", "write"; permission java.io.filepermission "/Test/text2.txt", "read"; permission java.awt.awtpermission "accesseventqueue"; ; Das Schlüsselwort codebase sagt uns, dass anschliessend die URL kommt mit dem Pfad zu den Klassendateien, für die die Permissions gelten sollen.

15 Seite 14 4 Starten von Applets/Applikationen 4.1 Applets Wenn keine Angaben dem appletviewer oder der VM des Browsers übergeben werden, dann hat das Applet keinen Zugriff auf Systemressourcen, den es läuft nur in der sogenannten Sandbox. Um nun einem Applet die nötigen Permissions mitteilen zu können, muss man explizit das entsprechende Policy-File angeben.. Der Programmaufruf mit dem appletviewer (enthalten im JDK) sieht dann wie folgt aus: appletviewer -J"-Djava.security.policy=policyfile" myapplet.html Hier ist policyfile das benötigte Policy-File, das die nötigen Permissions für das in myapplet.html gestarteten Applet enthält. Die Datei myapplet.html kann leicht mit dem HtmlConverter Tool, das im JDK enthalten ist, erstellt werden. Ganz bequem geht es, wenn man das mit folgendem Befehl startet: HtmlComverter -gui Mit ein paar Mausklicks auf der Benutzeroberfläche des HtmlConverter-Tools, hat man das benötigte HTML-File erzeugt. Es empfiehlt sich jedoch anschliessend noch den erzeugten HTML-Code zu überprüfen, da ich aus persönlicher Erfahrung gemerkt habe, dass zum Teil bei den End-Tags an Stelle eines / ein \ eingefügt wird. Auch die Header- und Body-Tags musste ich noch manuell hinzufügen. Um das Applet im Browser laufen zu lassen muss man der Virtual Machine des benutzten Java-Plugin die Option -Djava.security.policy=policyfile mitgeben, damit die VM weiss, wo die benötigten Permissions nachzuschauen sind.

16 Seite Applikationen Wenn man eine Java-Applikation ohne Angaben des Security Managers und des Policy-Files startet und auch keinen Security Manager im Programm setzt, hat die Applikation defaultmässig vollen Zugriff auf alle Systemressourcen. Die Applikation wird also als fully trusted angeschaut, genau wie im Security Model des JDK 1.0 und 1.1, in denen lokaler Code immer vollen Zugriff auf die Systemressourcen hat. Um nun die Zugriffsmöglichkeiten einer Applikation einschränken zu können, muss man beim Starten einer Applikation explizit den zu verwendenden Security Manager und das benötigte Policy-File angeben. Der Applikationsaufruf könnte zum Beispiel wie folgt aussehen: java -Djava.security.manager -Djava.security.policy=policyfile MyMainClass Mit der Option -Djava.security.manager sagt man der VM, dass man den default Security Manager benützen möchte. Wie bereits erwähnt, kann pro Programm nur ein Security Manager geladen werden, es kann also nachträglich nicht mehr ein anderer SecurityManager gesetzt werden. Wenn man also im Programm selber den benötigten Security Manager mit System.setSecurityManager(...) setzt, dann muss man diese Option beim Programmstart weglassen. Ansonsten wird eine Exception geworfen.

17 Seite 16 5 Neue Möglichkeiten und Gefahren Das Java 2 Security-Model bietet eine Reihe von neuen Möglichkeiten. Erstmals wird erlaubt auch lokalen Code (Java-Applikationen) als unvertrauenswürdig anzuschauen. Dies hat seine Berechtigung, denn immer mehr werden auch Applikationen via Internet heruntergeladen. Wenn sie von einer vertrauenswürdigen Quelle stammen und dazwischen nicht verändert wurden wäre dies kein Problem, jedoch weiss der Benutzer oft nicht wer das betreffende Programm geschrieben hat. Policy-Files sind hier von grosser Bedeutung, denn nun kann man den Zugriff auf Systemressourcen überwachen, bzw. begrenzen, so dass auch gefährlicher Code (malicious code) keinen, oder nur sehr begrenzten, Schaden anrichten kann. Applets hatten wie erwähnt in JDK 1.0 keinen Zugriff auf Systemressourcen und liefen defaultmässig in einem Sandkasten (sandbox). Der Einsatz von Applets und deren Funktionalität war daher sehr begrenzt. Mit dem Java 2 Security-Model besteht nun die Möglichkeit anhand von einem Policy-File einem Applet gezielt (Angabe der codebase in Form einer URL) Zugriffe auf Systemressourcen zu gewähren. Dadurch hat sich das Einsatzgebiet von Applets drastisch erhöht. Beispiel für ein neues Applet wäre, dass der Benutzer sich auf seinem PC in einem Editor eine kleine Einkaufsliste zusammengestellt hat. Er startet den Browser und lädt die HTML-Seite mit dem Applet des Verkäufers (z.b. Hier kann er nun seine Einkaufsliste von einem bestimmten Ordner (und nur von diesem) einlesen und den Einkauf tätigen. Das Erlauben von Zugriffen auf Systemressourcen, gegeben durch Policy-Files, birgt besonders für Applets (eigentlich jeglicher Java-Code der Remote geladen werden muss und somit als CodeBase eine URL hat) Risiken. Man überlege sich einmal was passieren würde, wenn jemand die URL, die Zugriff auf die Systemressourcen des Benutzerrechners hat, vortäuschen würde. Es würde keine Warnung geben, denn der Rechner, insbesondere Java Security, meint ja, dass die Klassendateien vom richtigen Ort kommen und der vielleicht gefährliche Code hat Zugriff auf die freigegebenen Ressourcen. Dieses Problem wurde jedoch von Java berücksichtigt und es liefert weitere Sicherheitsmechanismen, die dieses "Loch" stopfen. So kann man Java-Code signieren, so dass man überprüfen kann, ob der zu ladende Code, auch wenn er von einer falschen (bzw vorgetäuschten) Adresse kommt, wirklich dem original Code entspricht.

18 Seite 17 Schlussfolgerung Wir haben gesehen wie sich das Java Security Modell über die letzen Jahre gewandelt hat, von einem Modell, das nur trusted und untrusted Code kannte, zu einem Modell das erlaubt für jeglichen Java-Code wohldefinierte Permissions zu erteilen und somit den Zugriff auf Systemressourcen zu erlauben. Policy-Files im Zusammenspiel mit dem Security Manager und andere Security Komponenten bieten, wenn gezielt und bewusst eingesetzt, ein starkes Sicherheitskonzept. Es ist jedoch zu bemerken, dass es nicht der absolute Schutz vor Attacken ist, jedoch wird dadurch die Zahl der möglichen Attacken wesentlich eingeschränkt. Zu guter letzt ist noch zu sagen, dass der Einsatz von Policy-Files, insbesondere das Erteilen von Permissions auf kritische Systemressourcen, gut abgewägt werden muss, damit nicht leichtsinnig eine Tür ins System für alle aufgemacht wird.

19 Seite 18 A. Anhang A1. Applikationsbeispiel Code Folgende Unterkapitel enthalten den kompletten Code der Demo-Applikation. Es ist zu beachten, dass sich die beiden Files in einem Package (Verzeichnis mit Namen secure1) zu befinden haben. Um den Code testen zu können müssen sie im Verzeichnis C: folgende Struktur errichten C:\Test\classes\secure1\ Plazieren sie die beiden Files FileIO.java und PasswordSecurityManager.java in dieses Verzeichnis und compilieren sie sie. Das Policy-File ist im Ordner Test zu platzieren, zudem müssen sie im selben Ordner ein leeres File text.txt und ein zweites File text2.txt, das einen Text enthält erstellen. Wenn sie diese Angaben verwendet haben und j2sdk1.4.0 oder die dazu passende Runtime Environment installiert und die PATH-Variable gesetzt ist, können sie das Demo mit folgendem Befehl starten: C:\Test\classes>java -Djava.security.policy=secure.policy secure1.fileio A1.1. FileIO.java package secure1; /** * <p>title: Secure1</p> * <p>description: Applikations Test</p> * <p>copyright: Copyright (c) 2003</p> * <p>company: fh-aargau</p> Martin Bodmer 1.0 */ import java.awt.*; import java.awt.event.*; import java.io.*; import javax.swing.*; public class FileIO extends JFrame implements ActionListener {

20 Seite 19 JLabel text, clicked; JButton button, clickbutton; JPanel panel; JTextField textfield; public FileIO(){ //Begin Constructor setfont(new Font("Helvetica", Font.PLAIN, 14)); text = new JLabel("Text to save to file:"); clicked = new JLabel("Text retrieved from file:"); button = new JButton("Click Me"); button.addactionlistener(this); clickbutton = new JButton("Click Again"); clickbutton.addactionlistener(this); textfield = new JTextField(20); panel = new JPanel(); panel.setlayout(new BorderLayout()); panel.setbackground(color.white); getcontentpane().add(panel); panel.add("north", text); panel.add("center", textfield); panel.add("south", button); //End Constructor public void actionperformed(actionevent event){ Object source = event.getsource(); if(source == button){ JLabel label = new JLabel(); try{ //Write to file String text = textfield.gettext(); byte b[] = text.getbytes(); File outputfile = new File("/Test/text.txt"); FileOutputStream out = new FileOutputStream(outputFile);

21 out.write(b); out.close(); //Read from file File inputfile = new File("/Test/text2.txt"); FileInputStream in = new FileInputStream(inputFile); byte bt[] = new byte[(int)inputfile.length()]; int i; i = in.read(bt); String s = new String(bt); label.settext(s); in.close(); catch(java.io.ioexception e){ System.out.println(e.toString()); catch(java.lang.securityexception ex){ System.out.println("Security Exception!!!"); System.out.println(ex.toString()); //Display text read from file panel.removeall(); panel.add("north", clicked); panel.add("center", label); panel.add("south", clickbutton); panel.validate(); panel.repaint(); Seite 20 if(source == clickbutton){ panel.removeall(); panel.add("north", text); textfield.settext(""); panel.add("center", textfield); panel.add("south", button); panel.validate(); panel.repaint(); public static void main(string[] args){ System.out.println("Hello together!");

22 BufferedReader buffy = new BufferedReader( new InputStreamReader(System.in)); try { System.setSecurityManager( new PasswordSecurityManager("pwd", buffy)); catch (SecurityException se) { System.err.println("SecurityManager already set!"); Seite 21 try{ UIManager.setLookAndFeel( UIManager.getCrossPlatformLookAndFeelClassName()); catch (Exception e) { System.err.println("Couldn't use the cross-platform" + "look and feel: " + e); JFrame frame = new FileIO(); frame.settitle("example"); WindowListener l = new WindowAdapter() { public void windowclosing(windowevent e) { System.exit(0); ; frame.addwindowlistener(l); frame.pack(); frame.setvisible(true); A1.2. PasswordSecurityManager.java package secure1; /** * <p>title: Secure1</p> * <p>description: Appl Test 1</p> * <p>copyright: Copyright (c) 2003</p> * <p>company: fh-aargau</p> Martin Bodmer

23 1.0 */ Seite 22 import java.io.*; public class PasswordSecurityManager extends SecurityManager { private String password; private BufferedReader buffy; public PasswordSecurityManager(String p, BufferedReader b) { super(); this.password = p; this.buffy = b; private boolean accessok() { int c; String response; System.out.println("What's the secret password?"); try { response = buffy.readline(); if (response.equals(password)) return true; else return false; catch (IOException e) { return false; public void checkread(string filename) { //Mention file by name so don't get prompted for password //for everything the application loads to create itself System.out.println("checkRead for: "+filename); if((filename.equals("\\test\\text2.txt"))){ if(!accessok()){ System.out.println("checkRead: access not OK!"); super.checkread(filename);

24 Seite 23 throw new SecurityException("No Way!"); else { System.out.println("checkRead: access OK!"); FilePermission perm = new FilePermission("/Test/text2.txt", "read"); checkpermission(perm); public void checkwrite(string filename) { //Mention file by name so don't get prompted for password //for everything the application loads to create itself System.out.println("checkWrite for: "+filename); if((filename.equals("\\test\\text.txt"))){ if(!accessok()){ System.out.println("checkWrite: access not OK!"); super.checkwrite(filename); throw new SecurityException("No Way!"); else { System.out.println("checkWrite: access OK!"); FilePermission perm = new FilePermission("/Test/text.txt", "write"); checkpermission(perm); A1.3. secure.policy grant codebase "file:/c:/test/classes/-" { permission java.io.filepermission "/Test/text.txt", "write"; permission java.io.filepermission "/Test/text2.txt", "read"; permission java.awt.awtpermission "accesseventqueue"; permission java.awt.awtpermission "showwindowwithoutwarningbanner"; ;

25 A2. Bibliographie Seite 24 Advanced Programming for the Java 2 Platform Securing Java Java security evolution and concepts, Part2 Java security evolution and concepts, Part3 Java security evolution and concepts, Part4 Java security evolution and concepts, Part5 Java 2 SDK Dokumentation