Java-Sicherheit: So installieren Sie den Sicherheitsmanager und passen Ihre Sicherheitsrichtlinie an

Der Artikel dieses Monats setzt die Diskussion über Javas Sicherheitsmodell fort, das im August in "Under the Hood" begann. In diesem Artikel habe ich einen Überblick über die in die Java Virtual Machine (JVM) integrierten Sicherheitsmechanismen skizziert. Ich habe mir auch einen Aspekt dieser Sicherheitsmechanismen genau angesehen: die integrierten Sicherheitsfunktionen der JVM. In der September-Kolumne habe ich die Architektur des Klassenladeprogramms und in der Oktober-Kolumne den Klassenprüfer untersucht. In diesem Teil der Sicherheitsreihe beschreibe ich den Sicherheitsmanager - das vierte und letzte Stück der zentralen Sicherheitsarchitektur der JVM - und schließe mit einer kurzen Diskussion der Art und Weise, wie die Sicherheitsstrategie von Java über die Architektur der JVM hinausgeht.

Der Sicherheitsmanager und die Java-API

Wie in "Under the Hood" vom letzten Monat beschrieben, können Sie mithilfe eines Klassendateiverifizierers verhindern, dass sich von verschiedenen Klassenladern geladener Code innerhalb der JVM gegenseitig stört. Zum Schutz von Assets außerhalb der Java Virtual Machine müssen Sie jedoch einen Sicherheitsmanager verwenden. Der Sicherheitsmanager definiert die Außengrenzen der Sandbox. (Eine Auffrischung der Java-Sandbox finden Sie im ersten Abschnitt meiner August-Spalte "Under the Hood".)

Ein Sicherheitsmanager ist eine Klasse, die von der Klasse abstammt java.lang.SecurityManager. Da sie in Java geschrieben sind, können Sicherheitsmanager angepasst werden. Mit einem Sicherheitsmanager können Sie eine benutzerdefinierte Sicherheitsrichtlinie für eine Anwendung erstellen.

Die Java-API erzwingt die benutzerdefinierte Sicherheitsrichtlinie, indem sie den Sicherheitsmanager um Erlaubnis bittet, Maßnahmen zu ergreifen, bevor er etwas tut, das möglicherweise unsicher ist. Für jede potenziell unsichere Aktion gibt es im Sicherheitsmanager eine Methode, die definiert, ob diese Aktion von der Sandbox zugelassen wird oder nicht. Der Name jeder Methode beginnt mit "check", checkRead()definiert also beispielsweise, ob ein Thread in eine angegebene Datei lesen darf checkWrite()oder nicht , und definiert, ob ein Thread in eine angegebene Datei schreiben darf oder nicht. Die Implementierung dieser Methoden definiert die benutzerdefinierte Sicherheitsrichtlinie der Anwendung.

Die meisten Aktivitäten, die durch eine "Check" -Methode geregelt werden, sind unten aufgeführt. Die Klassen der Java-API überprüfen mit dem Sicherheitsmanager, bevor sie:

  • Akzeptieren Sie eine Socket-Verbindung von einem angegebenen Host und einer angegebenen Portnummer
  • Ändern Sie einen Thread (ändern Sie seine Priorität, stoppen Sie ihn usw.)
  • Öffnen Sie eine Socket-Verbindung zu einem angegebenen Host und einer angegebenen Portnummer
  • Erstellen Sie einen neuen Klassenlader
  • Löschen Sie eine angegebene Datei
  • Erstellen Sie einen neuen Prozess
  • Beenden Sie die Anwendung
  • Laden Sie eine dynamische Bibliothek, die native Methoden enthält
  • Warten Sie auf eine Verbindung an einer angegebenen lokalen Portnummer
  • Laden Sie eine Klasse aus einem angegebenen Paket (wird von Klassenladeprogrammen verwendet).
  • Fügen Sie einem angegebenen Paket eine neue Klasse hinzu (wird von Klassenladeprogrammen verwendet).
  • Zugriff auf oder Änderung von Systemeigenschaften
  • Greifen Sie auf eine angegebene Systemeigenschaft zu
  • Aus einer angegebenen Datei lesen
  • Schreiben Sie in eine angegebene Datei

Da die Java-API immer mit dem Sicherheitsmanager Rücksprache hält, bevor sie eine der oben aufgeführten Aktivitäten ausführt, führt die Java-API keine Aktion aus, die gemäß der vom Sicherheitsmanager festgelegten Sicherheitsrichtlinie verboten ist.

Vom Sicherheitsmanager nicht geschützte Bereiche

Zwei Aktionen, die in der obigen Liste nicht vorhanden sind und möglicherweise unsicher sind, sind die Speicherzuweisung und der Aufruf von Threads. Derzeit kann ein feindliches Applet den Browser eines Benutzers zum Absturz bringen, indem:

  • Zuweisen von Speicher, bis er aufgebraucht ist
  • Fäden abfeuern, bis alles langsamer wird

Diese Art von Angriffen wird als Denial-of-Service- Angriff bezeichnet, da sie Benutzern die Verwendung ihrer eigenen Computer verweigern. Mit dem Sicherheitsmanager können Sie keine Begrenzung für die Erstellung des zugewiesenen Speichers oder Threads erzwingen. ( In der Security Manager-Klasse gibt es keine checkAllocateMemory()oder keine checkCreateThread()Methoden.) Folgende andere Arten feindlicher Applets sind derzeit möglich:

  • Applets, die nicht autorisierte E-Mails vom Computer des Benutzers senden
  • Applets, die auch nach dem Verlassen der Webseite störende Geräusche verursachen
  • Applets, die anstößige Bilder oder Animationen anzeigen

Ein Sicherheitsmanager reicht also nicht aus, um jede mögliche Aktion zu verhindern, die einen Benutzer beleidigen oder stören könnte. Abgesehen von den hier aufgeführten Angriffen versucht der Sicherheitsmanager jedoch, eine Überprüfungsmethode bereitzustellen, mit der Sie den Zugriff auf potenziell unsichere Aktionen steuern können.

Installieren eines Sicherheitsmanagers

Wenn eine Java-Anwendung gestartet wird, hat sie keinen Sicherheitsmanager. Nach Wahl kann die Anwendung eine installieren. Wenn kein Sicherheitsmanager installiert wird, gelten keine Einschränkungen für Aktivitäten, die von der Java-API angefordert werden. Die Java-API macht alles, was sie verlangt. ( Aus diesem Grunde Java - Anwendungen, die standardmäßig keine Sicherheitsbeschränkungen haben wie diejenigen, die die Aktivitäten von nicht vertrauenswürdigen Applets begrenzen.) Wenn die Anwendung tut einen Sicherheitsmanager installieren, dann , dass Sicherheitsmanager verantwortlich für die gesamte Lebensdauer werden von diese Anwendung. Es kann nicht ersetzt, erweitert oder geändert werden. Ab diesem Zeitpunkt erfüllt die Java-API nur noch die Anforderungen, die vom Sicherheitsmanager genehmigt wurden.

Im Allgemeinen löst eine "Prüf" -Methode des Sicherheitsmanagers eine Sicherheitsausnahme aus, wenn die aktivierte Aktivität verboten ist, und kehrt einfach zurück, wenn die Aktivität zulässig ist. Daher umfasst die Prozedur, der eine Java-API-Methode im Allgemeinen folgt, wenn eine potenziell unsichere Aktivität ausgeführt werden soll, zwei Schritte. Zunächst prüft der Java-API-Code, ob ein Sicherheitsmanager installiert wurde. Wenn nicht, wird nicht mit Schritt zwei fortgefahren, sondern mit der möglicherweise unsicheren Aktion fortgefahren. Wenn ein Sicherheitsmanager hatinstalliert wurde, führt der API-Code Schritt zwei aus, in dem die entsprechende "check" -Methode im Sicherheitsmanager aufgerufen wird. Wenn die Aktion verboten ist, löst die "check" -Methode eine Sicherheitsausnahme aus, die dazu führt, dass die Java-API-Methode sofort abgebrochen wird. Die möglicherweise unsichere Aktion wird niemals ausgeführt. Wenn andererseits die Aktion zulässig ist, wird die "check" -Methode einfach zurückgegeben. In diesem Fall setzt die Java-API-Methode die möglicherweise unsichere Aktion fort und führt sie aus.

Obwohl Sie nur einen Sicherheitsmanager installieren können, können Sie den Sicherheitsmanager so schreiben, dass er mehrere Sicherheitsrichtlinien erstellt. Zusätzlich zu den "check" -Methoden verfügt der Sicherheitsmanager über Methoden, mit denen Sie bestimmen können, ob eine Anforderung direkt oder indirekt von einer Klasse gestellt wird, die von einem Klassenladeobjekt geladen wird, und wenn ja, von welchem ​​Klassenladeobjekt. Auf diese Weise können Sie eine Sicherheitsrichtlinie implementieren, die davon abhängt, welcher Klassenladeprogramm die Klassen geladen hat, die die Anforderung gestellt haben. Sie können die Sicherheitsrichtlinie auch basierend auf Informationen zu den vom Klassenladeprogramm geladenen Klassendateien ändern, z. B. ob die Klassendateien über ein Netzwerk heruntergeladen oder von der lokalen Festplatte importiert wurden. Obwohl eine Anwendung nur einen Sicherheitsmanager haben kann,Dieser Sicherheitsmanager kann eine flexible Sicherheitsrichtlinie festlegen, die je nach Vertrauenswürdigkeit des Codes variiert, der die möglicherweise unsichere Aktion anfordert.

Authentifizierung

Die in Java 1.1 im java.securityPaket eingeführte Unterstützung für die Authentifizierung erweitert Ihre Fähigkeit, mehrere Sicherheitsrichtlinien einzurichten, indem Sie eine Sandbox implementieren können, die je nachdem, wer den Code tatsächlich erstellt hat, unterschiedlich ist. Mit der Authentifizierung können Sie überprüfen, ob eine Reihe von Klassendateien von einem Anbieter als vertrauenswürdig eingestuft wurde und ob die Klassendateien auf dem Weg zu Ihrer virtuellen Maschine nicht geändert wurden. In dem Maße, in dem Sie dem Anbieter vertrauen, können Sie die Einschränkungen für den Code durch die Sandbox lockern. Sie können verschiedene Sicherheitsrichtlinien für Code festlegen, der von verschiedenen Anbietern stammt.

Links zu weiteren Informationen zur Authentifizierung und java.securityfinden Sie in den Ressourcen am Ende dieses Artikels.

Sicherheit jenseits der Architektur

Um effektiv zu sein, muss eine Sicherheitsstrategie für Computer oder Netzwerke umfassend sein. Es kann nicht ausschließlich aus einer Sandbox zum Ausführen von heruntergeladenem Java-Code bestehen. Beispielsweise spielt es möglicherweise keine Rolle, dass die Java-Applets, die Sie aus dem Internet herunterladen und auf Ihrem Computer ausführen, die Textverarbeitungsdatei Ihres streng geheimen Geschäftsplans nicht lesen können, wenn Sie:

  • Laden Sie routinemäßig nicht vertrauenswürdige native ausführbare Dateien aus dem Internet herunter und führen Sie sie aus
  • Werfen Sie zusätzliche gedruckte Exemplare Ihres Geschäftsplans weg, ohne sie zu vernichten
  • Lassen Sie Ihre Türen unverschlossen, wenn Sie weg sind
  • Stellen Sie jemanden ein, der Ihnen hilft, der tatsächlich ein Spion für Ihren Erzrivalen ist

Im Rahmen einer umfassenden Sicherheitsstrategie kann jedoch das Sicherheitsmodell von Java eine nützliche Rolle spielen.

Sicherheit ist ein Kompromiss zwischen Kosten und Risiko: Je geringer das Risiko einer Sicherheitsverletzung ist, desto höher sind die Sicherheitskosten. Die mit einer Computer- oder Netzwerksicherheitsstrategie verbundenen Kosten müssen gegen die Kosten abgewogen werden, die mit dem Diebstahl oder der Zerstörung der zu schützenden Informationen oder Computerressourcen verbunden wären. Die Art einer Computer- oder Netzwerksicherheitsstrategie sollte vom Wert der zu schützenden Vermögenswerte bestimmt werden.

Das Schöne an Javas Sicherheitsmodell ist, dass es nach dem Einrichten den größten Teil der Arbeit für Sie erledigt. Sie müssen sich keine Gedanken darüber machen, ob ein bestimmtes Programm vertrauenswürdig ist oder nicht - die Java-Laufzeit bestimmt dies für Sie. Wenn das Programm nicht vertrauenswürdig ist, schützt die Java-Laufzeit Ihre Assets, indem der nicht vertrauenswürdige Code in eine Sandbox eingeschlossen wird.

Javas allgemeine Sicherheitsstrategie

So wie Benutzer von Java-Software über eine umfassende Sicherheitsrichtlinie verfügen müssen, die ihren Anforderungen entspricht, beruht die Sicherheitsstrategie der Java-Technologie selbst nicht ausschließlich auf den in diesem Abschnitt beschriebenen Sicherheitsmechanismen für die Architektur. Ein Aspekt der Sicherheitsstrategie von Java besteht beispielsweise darin, dass jeder eine Lizenzvereinbarung unterzeichnen und eine Kopie des Quellcodes der Java Platform-Implementierung von Sun erhalten kann. Anstatt die interne Implementierung der Sicherheitsarchitektur von Java als geheime "Black Box" zu betrachten, steht sie jedem offen, der sie sich ansehen möchte. Dies ermutigt Sicherheitsexperten, die eine gute technische Herausforderung suchen, nach Sicherheitslücken in der Implementierung zu suchen. Wenn Sicherheitslücken entdeckt werden, können sie gepatcht werden. Daher ist die Offenheit der internen Implementierung von Java Teil von Java.s allgemeine Sicherheitsstrategie.

Neben der Offenheit gibt es einige andere Aspekte der gesamten Sicherheitsstrategie von Java, die die Architektur nicht direkt betreffen. Links zu weiteren Informationen hierzu finden Sie im Abschnitt Ressourcen am Ende dieses Artikels.

Fazit

Der Sicherheitsmanager trägt zum Sicherheitsmodell der JVM bei, indem er eine benutzerdefinierte Sicherheitsrichtlinie für Java-Anwendungen erstellt. Damit die Sicherheitsrichtlinie "kugelsicher" ist, müssen sowohl die Java-API als auch der Sicherheitsmanager selbst ordnungsgemäß implementiert werden. Ein Fehler in beiden Fällen kann zu einer Sicherheitslücke führen, die böswillige Programmierer ausnutzen können.

Die Anpassbarkeit des Sicherheitsmanagers ist eine der Stärken der Sicherheitsarchitektur von Java. Die "Prüf" -Methoden des Sicherheitsmanagers sind nur Java-Code. Sie können also frei entscheiden, unter welchen Umständen Ihre Anwendung möglicherweise unsichere Aktionen zulässt. Wenn Sie einen Algorithmus in Java-Code als "Prüf" -Methode des Sicherheitsmanagers ausdrücken können, kann dieser Algorithmus Teil der benutzerdefinierten Sicherheitsrichtlinie Ihrer Anwendung sein.

Bill Venners schreibt seit 12 Jahren professionell Software. Er ist im Silicon Valley ansässig und bietet Software-Beratungs- und Schulungsdienste unter dem Namen Artima Software Company an. Im Laufe der Jahre hat er Software für die Unterhaltungselektronik-, Bildungs-, Halbleiter- und Lebensversicherungsbranche entwickelt. Er hat in vielen Sprachen auf vielen Plattformen programmiert: Assemblersprache auf verschiedenen Mikroprozessoren, C unter Unix, C ++ unter Windows, Java im Web. Er ist Autor des Buches: Inside the Java Virtual Machine, veröffentlicht von McGraw-Hill.