Java Security Manager - Funktionsweise

[JCL (Gast)]

Hallo,

in Java lässt sich der Zugriff auf manche Ressourcen (Netzwerk, 
Dateisystem, usw) durch einen Security Manager und eine Policy 
einschränken.
Dabei ist es auch möglich, einzelnen Komponenten/Libraries selektiv den 
Zugriff zu erlauben bzw. zu verbieten.

Wie ist das aber technisch genau umgesetzt?
Die eigentlichen Syscalls müssen ja von der VM aufgerufen werden, das 
geht ja in reinem Java nicht.
An welcher Stelle werden nun die entsprechenden Checks durchgeführt?
Ist das in die VM hart reingecodet oder in der Class Library zu finden?

Laut Oracle Doku 
(https://docs.oracle.com/javase/7/docs/api/java/lang/SecurityManager.html) 
ist das folgendermaßen:

The SecurityManager class contains many methods with names that begin 
with the word check. These methods are called by various methods in the 
Java libraries before those methods perform certain potentially 
sensitive operations.

Daraus schließe ich, dass diese Checks in der Class Library durchgeführt 
werden.
Was hindert einen jetzt aber daran, den entsprechenden Code aus der 
Class Library selber zu implementieren und diese Checks einfach zu 
löschen?
Könnte man dann nicht einfach von unpriviligiertem Code aus auf alle 
Ressourcen zugreifen?

Viele Dank schonmal für jegliche Klarstellung

[Felix U. (ubfx)]

Interessante Frage.
Wenn wir als Beispiel mal den FileReader aus dem Artikel, den du 
verlinkt hast, nehmen. Der kreiert intern einen FileInputStream, und der 
wiederum sieht so aus:

public FileInputStream(File paramFile)
    throws FileNotFoundException
{
    String str = paramFile != null ? paramFile.getPath() : null;
    SecurityManager localSecurityManager = System.getSecurityManager();
    if (localSecurityManager != null) {
        localSecurityManager.checkRead(str);
    }
    if (str == null) {
        throw new NullPointerException();
    }
    if (paramFile.isInvalid()) {
        throw new FileNotFoundException("Invalid file path");
    }
    this.fd = new FileDescriptor();
    this.fd.attach(this);
    this.path = str;
    open(str);
}

Hier finden also die Checks ganz normal in Java implementiert statt. 
Interessant wird es in der open Funktion, die auch noch Java ist:

private void open(String paramString)
    throws FileNotFoundException
{
    open0(paramString);
}

Und open0 ist jetzt eine native API. Das 0 deutet immer auf die nativen 
Syscallwrapper hin:

private native void open0(String paramString)
    throws FileNotFoundException;

JCL schrieb:
> Die eigentlichen Syscalls müssen ja von der VM aufgerufen werden, das
> geht ja in reinem Java nicht.

Jap. Die meisten nativen Funktionen sind in libjava.so bzw java.dll 
implementiert. Und da finden wir auch in den Exports:

RVA         Name
00002B38    Java_java_io_FileInputStream_open0

Diese Funktion implementiert keine weiteren Checks. Wenn du es also 
schaffen würdest, open() oder open0() aus deiner Java-App zu callen, 
dann hast du den SecurityManager umgangen. Das Problem ist aber, dass 
sowohl open() als auch open0() private deklariert sind. Und darauf 
beruht die Sicherheit des ganzen :)

[JCL (Gast)]

Felix U. schrieb:
> Das Problem ist aber, dass
> sowohl open() als auch open0() private deklariert sind. Und darauf
> beruht die Sicherheit des ganzen :)

Ah okay, clever.
Vielen Dank für die ausführliche Erklärung.

Ich beschäftige mich an meiner Uni gerade mit einem Paper über die 
Sicherheit des Security Managers, dabei kam mir beiläufig die Frage auf, 
wie das eigentlich auf unterster Ebene gelöst ist.

Im Prinzip ist das ja ein mächtiges Konzept, aber gibt es heutzutage 
überhaupt noch Anwendungen, die Gebrauch vom Java Security Manager 
machen?
Java Applets in Webseiten scheinen ja langsam auszusterben, auf Android 
wird zwar viel Java eingesetzt, die Berechtigungen sind aber, soweit ich 
weiß, alle auf OS Ebene, zumal jede App ja auch nativen Code ausführen 
kann.

Tomcat zB. scheint das zumindest optional vorzusehen, um eine 
zusätzliche Schicht an Sicherheit zu haben, falls man irgendwo sonst was 
falsch konfiguriert:
https://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html

[Felix U. (ubfx)]

JCL schrieb:
> gibt es heutzutage
> überhaupt noch Anwendungen, die Gebrauch vom Java Security Manager
> machen?

Gute Frage. Außer Applets und Apps (theoretisch) würde mir auch kein 
Szenario einfallen wo das sinnvoll ist. Ganz abgesehen davon, dass das 
ganze System ja von Beginn an so schlecht implementiert war, dass es zu 
jeder Zeit ein oder mehrere Lücken gab über die man aus Applets in einen 
Kontext mit Schreib- und Ausführrechten gekommen ist. Insofern ist wohl 
auch das Vertrauen in dieses "Sicherheitsfeature" nicht wirklich groß.