Der SecurityManager wird aus Java entfernt: Was das für Sie bedeutet

Das Paket java.security der Java Development Kit (JDK)-Bibliothek gehört zu den wichtigsten Paketen. Trotz regelmäßiger Updates wird es jedoch bei Weitem zu wenig genutzt.

Angesichts der zunehmenden Bedeutung von Cybersicherheits-Frameworks, darunter Zero Trust, müssen sich Java-Entwickler unbedingt mit den Sicherheitsbibliotheken von Java SE vertraut machen.

Wie jeder andere Bereich der Informationstechnologie ist auch die Cybersicherheit unberechenbar. Schließlich muss sie mit den neuesten Trends in der Cyberkriminalität Schritt halten. Eine Entwicklung der Java-Sicherheit – je nach Sichtweise Fortschritt oder Rückschritt – ist die Entfernung des SecurityManager. Doch warum ist das bedeutsam? Gibt es wirklich Grund zur Sorge? Dieser Artikel hilft Ihnen, diese Fragen zu beantworten.

Warum Java-Sicherheit notwendig ist

Java gilt dank Funktionen wie der Java Virtual Machine (JVM), Speicherverwaltung, robuster Ausnahmebehandlung und dem Fehlen von expliziten Zeigern (*d. h.* Referenzen) als von Natur aus sichere Sprache. Trotz dieser integrierten Funktionen nutzen Anwender Java möglicherweise weniger gern, weil es öffentlichkeitswirksame Schwachstellen wie Log4j gab.

Wichtig ist jedoch: Viele dieser Schwachstellen gehen auf Produkte, Drittanbieter und/oder Entwickler zurück (*d. h.* Entwickler schreiben keinen sicheren Code). Java weist zwar spezifische JDK-Schwachstellen auf beziehungsweise auf, etwa die Offenlegung sensibler Daten und Deserialisierungsprobleme, doch viele davon wurden bereits behoben oder werden derzeit behoben. So wurde JDK 20 mit einer verbesserten Optimierung der Kryptografie-Intrinsics für bestimmte Plattformen veröffentlicht.

Das bedeutet natürlich nicht, dass Java sämtliche Sicherheitsaufgaben automatisch übernimmt. Es liegt weiterhin an den Entwicklern, sicheren Code zu schreiben. Dazu müssen sie die Möglichkeiten und Grenzen der integrierten Sicherheitspakete von Java kennen. Häufig sind zudem APIs und Bibliotheken zur Sicherheit von Drittanbietern nicht erforderlich.

Das JDK umfasst Funktionen für Plattformsicherheit, Kryptografie, Zugriffskontrolle und Authentifizierung, Kommunikation sowie Public-Key-Infrastrukturen. Alle diese Funktionen werden im offiziellen Security Developer's Guide erläutert.

Zur Weiterentwicklung jeder Plattform und jedes Tools gehört auch, unsichere oder überflüssige Funktionen zu entfernen. Eine dieser Funktionen ist der SecurityManager.

Was ist der SecurityManager?

Der Java SecurityManager wurde als übergreifende Instanz für die Anwendungssicherheit entwickelt. Er wird beziehungsweise wurde verwendet, um Sicherheitsrichtlinien und Regeln für Java-Anwendungen festzulegen und so sicherzustellen, dass bestimmte Vorgänge unbedenklich sind. Die Klasse Java.lang.SecurityManager gibt es seit JDK 1.0.

Ursprünglich war der SecurityManager eine abstrakte Klasse. Später wurde sie jedoch nicht-abstrakt gemacht, um den Zugriff und die Verwendung zu erleichtern. Zwar ließ sich für jede Klasse ein neues SecurityManager-Objekt instanziieren, doch das entsprach nicht den bewährten Java-Programmierpraktiken. Stattdessen mussten Sie beim Ausführen Ihrer Anwendung eine Systemeigenschaft festlegen:

java -Djava.security.manager MyAPP

Alternativ konnten Sie ein SecurityManager-Objekt direkt instanziieren und es anschließend in Ihrem Code als Systemeigenschaft festlegen:

1SecurityManager sm = new SecurityManager();
2System.setSecurityManager(sm);

Der systemweite SecurityManager konnte anschließend in einer anderen Klasse wie folgt abgerufen werden:

SecurityManager securityManager = System.getSecurityManager();

Die Klasse SecurityManager besteht größtenteils aus einer Reihe von Prüfmethoden. Diese Methoden überprüfen, ob bestimmte Vorgänge einer Anwendung auf bestimmte Ressourcen zugreifen dürfen. Die wohl nützlichste ist die Methode checkPermission, die prüft, ob ein Vorgang bestimmte Ressourcen verwenden darf. Berechtigungsrichtlinien werden mithilfe direkter und geerbter Unterklassen der Klasse java.security.Permission festgelegt und kontrolliert.

Letztlich vereinfacht der SecurityManager die Sicherheit von Java-Anwendungen und ist einfach zu verwenden. Warum wurde er also als veraltet markiert?

Die Geschichte des SecurityManager

Jede neue Version von Java SE bringt zahlreiche Verbesserungen mit sich, viele davon dank des Java Community Process (JCP) und der JDK Enhancement Proposals. Letztere sind der Hauptgrund dafür, dass der SecurityManager zur Entfernung als veraltet markiert wurde.

In der Anfangszeit wurde die Klasse SecurityManager vor allem verwendet, um Sicherheitsrichtlinien für Applets festzulegen, die von den meisten Webplattformen nicht mehr unterstützt werden. Der Browser stellte den SecurityManager für jedes Applet bereit.

Die Java Applet API wurde 2017 mit der Veröffentlichung von Java 9 gemäß JEP289 schließlich als veraltet markiert. Allerdings wurde sie nicht zur Entfernung als veraltet markiert. Mit der Veröffentlichung von Java SE 17 wurden die Applet API und die zugehörigen Klassen gemäß JEP398 schließlich zur Entfernung als veraltet markiert.

So sollten die Programmiersprache und die API weiterentwickelt werden. Veraltete APIs wie diese waren so bedeutungslos geworden, dass sie für künftige JDK-Versionen nicht mehr benötigt wurden. Da der SecurityManager eng mit der Applet-Architektur verknüpft ist, wird er aus ähnlichen Gründen entfernt.

Warum wird der SecurityManager entfernt?

Heute ist der SecurityManager nicht mehr die effizienteste Methode, um Java-Code auf Client- und Serverseite abzusichern. Tatsächlich bietet die Java-Plattform für diese Aufgaben wirksamere Mechanismen.

Jede neue JDK-Version soll von Grund auf sicherer sein als die vorherige. Dadurch sind viele der versehentlichen Schwachstellen, denen der SecurityManager entgegenwirken sollte, nicht mehr relevant.

Da die Funktionalität des SecurityManager im letzten Jahrzehnt unverändert geblieben ist, kann er viele der heute verbreiteten Bedrohungen, Schwächen und Schwachstellen, mit denen Programmierer konfrontiert sind, nicht beheben. Tatsächlich war er nie dazu gedacht oder entwickelt worden, die heutigen Sicherheitsprobleme anzugehen. Da er aber weiterhin existiert, muss er mit allen verbundenen Klassen getestet werden.

Das verursacht einen unnötigen Wartungsaufwand. Die Zeit und Arbeit, die für den Erhalt des SecurityManager erforderlich sind, könnten stattdessen in das Testen von Klassen und Funktionen fließen, die für Entwickler heute relevanter sind. Einer der größten Vorteile der Architektur des SecurityManager ist zwar ihre intuitive Bedienbarkeit, doch die Konfiguration kann schwierig sein.

Zur Erinnerung: Der SecurityManager besteht hauptsächlich aus einer Reihe von Prüfmethoden. Eine nützliche Sicherheitsfunktion ist beispielsweise CheckPermission. Damit können Sie mithilfe Ihrer Java-Richtliniendatei Berechtigungen für eine Anwendung oder ein System überprüfen. Eine Richtlinie, die dem Code einer Anwendung Lesezugriff auf ein Verzeichnis gewährt, könnte so aussehen:

1grant codeBase "file:/home/source/" {
2    permission java.io.FilePermission "/resources/files", "read";
3};

Diese Konfiguration gewährt der Codebasis (allen Klassendateien) unter file:/home/source/ Zugriff auf alle Ressourcen im relativen Verzeichnis files. Um eine bestimmte Berechtigung zu prüfen, müssen Sie eine Unterklasse von `Permission` oder `BasicPermission` instanziieren. Sie bildet letztlich die in der Richtliniendatei festgelegte Berechtigung ab. In diesem Fall ist es das Objekt FilePermission:

FilePermission filePerm = new java.io.FilePermission("/resources/files", "read");

Da Richtlinien oft vom Kontext abhängen, müssen Sie ein Objekt abrufen, das den aktuellen Zugriffskontrollkontext des ausgeführten Codes repräsentiert. Anschließend können Sie mit SecurityManager die Berechtigungen für diesen Kontext prüfen:

1AccessControlContext accessCon = AccessController.getContext();
2 SecurityManager securityManager = System.getSecurityManager();
3 securityManager.checkPermission (filePerm, accessCon);

Wenn Ihre Richtlinien für den Dateizugriff Ihrem Code keinen Lesezugriff auf die Ressourcendatei gewähren, löst dieser Code eine SecurityException aus – genauer gesagt eine `AccessControlException`.

Dieses Verfahren scheint einfach, hat aber einige Nachteile. Detaillierte, fein abgestufte Berechtigungen und Richtlinien festzulegen, kann schwierig sein. Was ist zum Beispiel, wenn bestimmte Vorgänge oder Klassen Schreibzugriff auf eine bestimmte Datei in einem Verzeichnis erhalten sollen, obwohl Ihre Richtlinien diesen Zugriff verhindern?

Als Behelfslösung könnten Sie separate Verzeichnisse für Richtlinien-, Quell- und Ressourcendateien verwenden. Dann müssten Sie sorgfältig abgleichen und nachverfolgen, wie Ihre Berechtigungen mit den einzelnen Richtlinien zusammenhängen. Das ist höchst ineffizient, insbesondere wenn Sie eine Anwendung mit komplexen Richtlinien und Berechtigungen entwickeln.

Auch die Entwicklung von Bibliotheken und APIs, die SecurityManager verwenden, ist nicht einfacher. Bei Bibliotheken, die auf der SecurityManager-Architektur basieren, müssen Sie Ihrem Code einige der gleichen Berechtigungen erteilen wie der Bibliothek. Dazu müssen Sie die Dokumentation der Bibliothek nach den erteilten Berechtigungen durchsuchen – sofern es überhaupt eine ausführliche Dokumentation gibt.

Alternativ können Sie den Dateien der Bibliotheksabhängigkeit einfach alle Berechtigungen erteilen. Das entspricht jedoch nicht den modernen Zero-Trust-Sicherheitsprinzipien (*d. h.* dem Prinzip der geringsten Berechtigungen).

Ihre Anwendungen müssen funktionsfähig und sicher sein und Ressourcen effizient nutzen können, damit sie portabel sind. Der SecurityManager ist sehr ressourcenintensiv, insbesondere wenn Sie eine Anwendung mit einem komplexen Berechtigungs- und Richtliniengefüge verwenden oder entwickeln. Tatsächlich wird die JVM standardmäßig immer ohne aktivierten SecurityManager ausgeführt.

Der SecurityManager ist nicht nur funktional veraltet, sondern auch architektonisch bedeutungslos. Das heißt, es wird keinen direkten Ersatz geben. Wie geht es also weiter?

Die Zukunft des SecurityManager

Zum Zeitpunkt der Veröffentlichung dieses Artikels war JDK 20 gerade allgemein verfügbar geworden, und ein Großteil der Architektur des SecurityManager bestand weiterhin. Seit dem Vorschlag, den SecurityManager zu entfernen, wurden drei Versionen veröffentlicht. Da er mit so vielen Java-Klassen und -Bibliotheken verflochten ist, lässt er sich nur schwer entfernen, ohne die gesamte Java API zu beeinträchtigen. Selbst Jakarta EE umfasst zahlreiche Funktionen, die auf der Architektur des SecurityManager beruhen.

Eine vollständige Entfernung wird also nicht einfach sein. Geplant ist, sie in sicheren Schritten umzusetzen; begonnen wurde damit bereits, indem der SecurityManager in JDK 17 zur Entfernung markiert wurde. Außerdem warnt die JVM Nutzer, wenn ein SecurityManager dynamisch erstellt oder zugelassen wird.

Ab JDK 18 war der SecurityManager standardmäßig nicht mehr zugelassen. Wenn Entwickler versuchten, einen SecurityManager zu erstellen und festzulegen (setSecurityManger), wurde ein Fehler vom Typ UnsupportedOperationException ausgelöst. Die Funktionalität zur Unterstützung von Legacy-Code, der SecurityManager verwendet, ist zwar weiterhin vorhanden, doch alle, die diese Architektur noch nutzen, sollten den Umstieg in Betracht ziehen.

Das JDK bietet Alternativen zu vielen Funktionen des SecurityManager. Wer beispielsweise Berechtigungen für den Zugriff auf nativen Code kontrollieren möchte, kann die Foreign Function and Memory API (FFM) verwenden, die mit JDK 20 eingeführt wurde.

Alternativen zum SecurityManager

Der erste Schritt, um Ihren Code vom Java SecurityManager zu entkoppeln, besteht darin, herauszufinden, wo er verwendet wird. Er ist zwar in den neuesten JDK-Versionen mit Langzeitunterstützung (LTS), also 17 und 21, weiterhin verfügbar, gilt aber als veraltet. Unternehmen, die ein Upgrade von früheren LTS-Versionen wie JDK 11 oder 8 planen, sollten sich dessen bewusst sein. Veralteter Code sollte grundsätzlich entfernt oder aktualisiert werden, da er nur unzureichend gewartet wird und ein Sicherheitsrisiko darstellen kann. Mit jdeprscan können Sie veralteten Code in Ihren Klassendateien finden.

Die einzige echte Alternative zum SecurityManager, die sofort verfügbar ist, ist die Security Library des JDK. Entwickler sollten sich mit Oracles Secure Coding Guidelines for Java SE vertraut machen. Sicherer Code von Anfang an ist der wichtigste Schritt, um die Schwachstellen Ihres Projekts zu minimieren.

Die Suche nach veralteten APIs ist wichtig, aber nicht die einzige Sicherheitslücke, nach der Sie suchen sollten. Ebenso wichtig ist es, die Abhängigkeiten und Bibliotheken Ihres Projekts zu überprüfen. Entwickler nutzen häufig den SecurityManager, um zu überwachen und zu protokollieren, auf welche Ressourcen ihre Anwendungen zugreifen. Dafür kann eine Lösung eines Drittanbieters wie Snyk verwendet werden.

Snyk ist ein Developer-Security-Tool, das sich in Ihre Entwicklungsumgebung integrieren lässt und Sie bei der Analyse der Code- und Container-Sicherheit unterstützt. Es durchsucht die Konfigurationsdateien und Manifeste Ihres Projekts, um direkte und indirekte Abhängigkeiten mit bekannten Sicherheitslücken zu finden und zu kennzeichnen. Snyk behebt Ihre Sicherheitslücken automatisch, indem es Ihre Konfigurationsdateien patcht und alle Abhängigkeiten aktualisiert. Das Tool lässt sich in verschiedene Development-Tools und Workflows integrieren.

Snyk bietet eine Befehlszeilenschnittstelle (CLI), mit der Entwickler das Tool im Terminal oder in einem Continuous-Integration- und Continuous-Delivery-Workflow (CI/CD) verwenden können. Sie können das eigenständige Snyk-CLI-Tool herunterladen und installieren. Nachdem Sie es konfiguriert und sich authentifiziert haben, können Sie Ihre lokalen Projekte mit dem Befehl snyk test testen.

Mit dem Befehl snyk monitor bleiben Sie außerdem über neu auftretende Sicherheitslücken auf dem Laufenden. Snyk erstellt damit einen Snapshot Ihres Projekts, den Sie in der Webanwendung ansehen können, und sendet Ihnen E-Mail-Benachrichtigungen zu neu entdeckten Problemen mit Ihren Komponenten.

Hier sehen Sie eine kurze Demonstration der Befehle snyk test und snyk monitor:

Auch wenn Snyk Sicherheitslücken finden kann, ist es dennoch wichtig, die grundlegenden Prinzipien für sicheres Programmieren in Java einzuhalten. Wie das Sprichwort sagt: „Vorbeugen ist besser als heilen.“ Daher sollten Sie die Snyk CLI bei der Entwicklung zusammen mit einem CI-Tool verwenden – als Teil eines durchdachten DevSecOps-Prozesses.

In den letzten Jahren hat die Branche einen deutlichen Anstieg von Open-Source-Sicherheitslücken verzeichnet. Um Angriffe einzudämmen und zu verhindern, sollten Entwickler regelmäßig die Sicherheitslage ihrer Projekte und Workflows überprüfen. Tools wie Snyk werden regelmäßig aktualisiert und ermöglichen es Ihnen, Qualitäts- und Sicherheitsprüfungen zu automatisieren, indem Sie sie in Ihre CI/CD-Pipeline integrieren.

Da der SecurityManager kaum noch unterstützt wird, könnten Sie versucht sein, eine Java-Bibliothek oder API eines Drittanbieters mit ähnlicher Architektur oder Herangehensweise zu verwenden. Bibliotheken von Drittanbietern zählen seit jeher zu den größten Sicherheitsrisiken. Wenn Sie sich für diesen Weg entscheiden, sollten Sie Snyk Open Source verwenden, um sicherzustellen, dass Sie sichere Abhängigkeiten für Ihr Projekt einsetzen.

Fazit

Letztlich ist der SecurityManager veraltet. Es ist erstaunlich, dass es so lange gedauert hat, ihn offiziell zu entfernen. Und das sind keine schlechten Nachrichten. Ganz im Gegenteil: Die Java-Plattform wird dadurch deutlich sicherer und weniger überladen. Der SecurityManager war nie als allgemeines Tool für Cybersicherheit gedacht, auf das man sich verlassen sollte.

Wenn Sie die allgemeine Sicherheitslage Ihrer Projekte wirksamer verbessern möchten, sollten Sie ein Tool wie Snyk in Betracht ziehen. Damit können Sie Zero Trust in Ihren Entwicklungs-Workflow integrieren. Zusätzlich können Sie das Snyk Code IDE-Plugin für IntelliJ hinzufügen, um Ihren Code abzusichern und seine Qualität in Echtzeit sicherzustellen.