Weitere aktuelle Java-Titel finden Sie bei dpunkt.
 Inhaltsverzeichnis   Auf Ebene Zurück   Seite Zurück   Seite Vor   Auf Ebene Vor   Eine Ebene höher   Index


15.1.5

Sicherheit in Applikationen



Im Gegensatz zu Applets ist bei Applikationen standardmäßig kein SecuriyManager aktiv. Daher können Applikationen ohne weitere Maßnahmen Dateien erzeugen oder auch beliebige Netzwerkverbindungen erzeugen.

Mit Hilfe der Klasse ClassLoader können aber auch in eine Applikation zur Laufzeit neue Klassen über eine Verbindung zu einem anderen Rechner geladen werden. Es kann nun z. B. sein, dass man nur die Funktion einer Klasse, die geladen wird, kennt. Hat man nur Zugriff auf den Bytecode, kann man nicht beurteilen, ob diese Klasse nicht doch unbemerkt auf Dateien auf dem lokalen Rechner zugreift oder Informationen über eine Netzverbindung verschickt. Da bei Applikationen kein SecurityManager festgelegt ist, werden auch keine Operationen überprüft.

Sollen in einer Applikation trotzdem bestimmte Operationen nicht möglich sein, wie z. B. das Löschen von Dateien, so ist es notwendig, einen SecurityManager in der Applikation zu installieren. Dies erfolgt mit der Methode setSecurityManager() der Klasse System:
  System.setSecurityManager(new SecurityManager());
Danach ist der SecurityManager aktiv und stellt die Einhaltung der im Abschnitt 15.1.6 beschriebenen Policies sicher.

Ableiten von SecurityManager

In diesem Abschnitt wird beschrieben, wie man Sicherheitseinstellungen bis JDK 1.1 bei Applikationen mit einem eigenen SecurityManager vornehmen konnte. Die Zuteilung der Berechtigungen an unterschiedliche Anwendungen erfolgte bis dahin durch Ableiten einer eigenen Klasse von SecurityManager. Dort werden die vergebenen Berechtigungen explizit in Form von Quellcode festgelegt.

Seit JDK 1.2 ist es nicht mehr erforderlich, eine Unterklasse abzuleiten, da die Berechtigungen als Klartext in Policy-Dateien festgehalten werden. Die Berechtigungen sind also unabhängig vom Quellcode. Um einen Eindruck von der Entwicklung des JDK zu bekommen wird an dieser Stelle dennoch die Vorgehensweise bei der Definition eines eigenen SecurityManagers vorgeführt.

SecurityManager definiert eine Reihe von Methoden, in denen abgeprüft wird, ob ein bestimmter Zugriff erlaubt ist oder nicht. Wird der Zugriff verweigert, lösen diese Methoden eine SecurityException aus, ansonsten kehren sie einfach zurück.

Tabelle 15.1: Eine Auswahl der Methoden des SecurityManagers
checkAccess(Thread)Bei Zugriff auf einen Thread
checkConnect(String, int)Bei Verbindungen zu einem Host
checkDelete(String)Beim Löschen von Dateien
checkRead(Sting)Beim lesenden Zugriff auf Dateien
checkWrite(String)Beim schreibenden Zugriff auf Dateien

Eine kleine Auswahl kann Tabelle 15.1 entnommen werden. Dies sind jedoch längst nicht alle Überprüfungsmethoden, die ein SecurityManager besitzt. Die Klasse SecurityManager bietet noch eine Vielzahl weiterer Methoden, die zur Überwachung bestimmter Operationen dienen.

Wenn ein SecurityManager nun bestimmte Operationen unterbinden soll, müssen die dafür relevanten Methoden überschrieben werden. Dies soll eine Applikation verdeutlichen, die das Löschen und Beschreiben von Dateien unterbindet. Außerdem soll ausschließlich die Datei /tmp/test.dat gelesen werden können. Der hierfür benutzte SecurityManager hat folgenden Aufbau:
  class IOSecurityManager extends SecurityManager {
  
    public void checkPropertyAccess(String key) {
      // Abfrage von Dateipfad-Trennungszeichen erlauben
      if ( ! key.equals("file.separator")
            && (! key.equals("path.separator")))
        throw new SecurityException("Property not allowed");
    }
  
    public void checkRead(String file) {
      // Nur Lesen von '/tmp/test.dat' erlaubt
      if (! file.equals("/tmp/test.dat"))
        throw new SecurityException(
                             "you mustn't open this file");
    }
  
    public void checkDelete(String file) {
      // Es darf keine Datei geläscht werden
      throw
         new SecurityException("you mustn't delete files");
    }
  
    public void checkWrite(String file) {
      // Es darf in keine Datei geschrieben werden
      throw
         new SecurityException("you mustn't write files");
    }
  }
Die für das Löschen und Beschreiben von Dateien relevanten Methoden sind checkDelete(String) und checkWrite(String). Die Methoden bekommen jeweils den Namen der Datei übergeben, die gelöscht oder beschrieben werden soll. Sie haben die Aufgabe, den Zugriff festzulegen. Anhand der Parameter (in diesem Fall der Dateiname) muss innerhalb der Methode geprüft werden, ob zugegriffen werden darf oder nicht. Ist der Zugriff nicht zulässig, muss eine SecurityException ausgelöst werden, wie es in folgender Zeile dargestellt ist:
  throw
     new SecurityException("you mustn't write files");
Die anderen Methoden sind analog implementiert. Um den selbstdefinierten SecurityManager zu aktivieren, muss die Methode System.setSecurityManager() aufgerufen werden, der ein Exemplar der abgeleiteten Klasse übergeben wird:
  System.setSecurityManager(new MySecurityManager());

Material zum Beispiel


 Inhaltsverzeichnis   Auf Ebene Zurück   Seite Zurück   Seite Vor   Auf Ebene Vor   Eine Ebene höher   Index

Copyright © 2002 dpunkt.Verlag, Heidelberg. Alle Rechte vorbehalten.