Ausführen von jar-Dateien unterbinden

[Marci]

Hallo,

ich suche eine Möglichkeit auf Windows-/Linux-Systemen das Ausführen lokaler jar-Dateien zu unterbinden. Allerdings sollen mit Hilfe einer Whitelist bestimmte Dateien hiervon ausgenommen werden.
Für Applets ist dies mit Hilfe des Policytools (\jre*\bin\policytool.exe) möglich. Kann das Tool auch für die Sperrung von lokalen jar-Dateien verwendet werden? Kennt Ihr eine andere Möglichkeit?

Danke & Grüße

Marci

 

[pinhead84]

Ich bezweifle, dass dies zuverlässig funktionieren könnte. Solange ein Anwender lokalen Zugriff auf den Rechner hat, kann man ihn nur schwer davon abhalten den von dir angesprochenen Mechanismus zu umgehen. Was hindert den Anwender daran eine separate JRE herunterzuladen, in seinem Profil zu installieren und die gesperrte JAR-Datei dann mit dieser ungeschützten JVM auszuführen?

Es ist die gleiche 'Krux', wie bei verschlüsseltem Bytecode. Dadurch, dass der Anwender nach Belieben seine JVM anpassen kann (Open Source sei Dank), sind solche Mechanismen zum Scheitern verurteilt. Wen es interessiert, dieser Artikel beschreibt den Sachverhalt recht anschaulich.


PS: Ich lasse mich gern vom Gegenteil überzeugen.

 

[Marci]

Hi!

Man könnte unter Zuhilfenahme genereller (systemweiter) Software-Policies das Ausführen von Dateien unterbinden und so die Installation einer "eigenen" JRE unterbinden. Nach dem Motto: Nutzer darf Dateien nur aus Ordnern ausführen auf die er keine Schreibrechte hat.
Oder habe ich Deinen Einwand missgedeutet?

Grüße

Marci

 

[pinhead84]

Mein geschildertes Szenario könnte man mit solchen Policies sicherlich umgehen. Du könntest auch Unix-seitig einfach die Leserechte auf dem zu schützenden JAR-Archiv entsprechend einschränken. Bei Windows wird das sicherlich auch gehen.

Solange der Anwender aber lesenden Zugriff auf deine zu schützende JAR-Datei bekommt, kann er diese auch entpacken und gelangt an den Bytecode. Erfahrungsgemäß ist der Bytecode nicht sonderlich geschützt (bzw. kann auch nicht sonderlich geschützt werden, siehe letzter Beitrag), sodass der Anwender:

(a) Die class-Dateien aus dem JAR-Archiv entpacken kann um diese beim Start der JVM manuell in den Classpath einzufügen.
(b) Die class-Dateien dekompiliert, Quelltext refaktorisiert etc.
(c) Das JAR-Archiv auf einen externen Rechner kopiert, wo keine systemweiten Policies existieren.

Lange Rede kurzer Sinn. Wer meint, sein geistiges Eigentum schützen zu müssen, ist mit Java an der falschen Adresse. Gleiches gilt für Einschränkungen, wie du sie angesprochen hast. Mit etwas Zeit und Java-Kenntnissen, kommt man an solchen Policies vorbei.