# SecurityManager für einzelne Klassen/Threads?



## renwal (29. Jun 2012)

Hallo!

Für meine Lernplattform arbeite ich gerade am Plugin-System und stehe vor folgendem Problem: Die einzelnen Plugins sollen mit eingeschränkten Rechten laufen, um dafür zu sorgen, dass diese Plugins Dritter keinen Schaden anrichten können. Nun stehe ich jedoch vor dem Problem, dass ich nur einen SecurityManager setzen kann, der dann aber für alle Klassen/Threads gilt. Somit sperrt sich meine Anwendung quasi selbst aus - ein Zugriff auf den Programmordner wird verweigert, sodass ich die Plugins nicht einmal mehr starten kann.

Gibt es eine Möglichkeit, den SecurityManager anzuweisen, von einem bestimmten ClassLoader geladene Klassen einzuschränken und alle anderen nicht?


----------



## Spacerat (29. Jun 2012)

Die Klasse [c]java.lang.SecurityManager[/c] ist ja nicht *final* und das heisst, man kann eigene implementieren und demnach wohl auch einbinden bzw. setzen. Wie das geht, steht in diversen Tutorials, die man im Netz zu Unmengen findet.


----------



## Lumaraf (29. Jun 2012)

Schau dir mal die Klasse 
	
	
	
	





```
java.security.ProtectionDomain
```
. Die ist afaik dazu gedacht anhand vom Ursprungsort der ausgeführten Klasse unterschiedliche Rechte zu vergeben.


----------



## renwal (30. Jun 2012)

@Spacerat: Dass der SecurityManager nicht final ist, weiß ich auch. Es geht ja nur darum, dass der SecurityManager mitbekommt, von wo der Aufruf kommt und je nachdem, ob er aus einem Plugin kommt, die Rechte einschränkt oder eben nicht.

@Lumaraf: Auf diese Weise bekomme ich aber nur den Speicherort einer Klasse heraus. Das ist ein guter Ansatz, aber wie bekomme ich jetzt eben den Zeiger auf die Klasse, die den Aufruf ausgeführt hat?

Ein Beispiel habe ich noch gefunden, dort wird der Stack analysiert und dann entschieden, ob die Berechtigung gegeben wird.


----------



## Spacerat (30. Jun 2012)

renwal hat gesagt.:


> @Spacerat: Dass der SecurityManager nicht final ist, weiß ich auch. Es geht ja nur darum, dass der SecurityManager mitbekommt, von wo der Aufruf kommt und je nachdem, ob er aus einem Plugin kommt, die Rechte einschränkt oder eben nicht.


Aber das man nicht finale Klassen erweitern kann weisst du anscheinend nicht. Eigenen SecurityManager implementieren, entsprechende Methoden überschreiben und am Schluss mit [c]System.setSecurityManager(mySecurity)[/c] diesen setzen.
Welche Methoden da im Allgemeinen überschrieben werden müssen, entzieht sich bislang meiner Kenntnis. Ich würde nun entweder Literatur im Internet suchen oder einen Dummy-Manager implementieren um zu erfahren, wie ein solcher Mechanismus funktioniert.


----------



## renwal (30. Jun 2012)

So weit bin ich doch schon längst. Es gibt eine Klasse 
	
	
	
	





```
PluginSecurityManager extends SecurityManager
```
, dort habe ich durch Overrides die Methoden geändert, bei denen ich die Zugriffsrechte geben möchte (erst ein paar, bin noch am basteln). Wenn ich diesen PluginSecurityManager jetzt setze, wirkt er sich aber auch auf meine Anwendung und nicht nur auf die Plugins aus. Und genau das gilt es ja zu vermeiden.

Und ganz ehrlich: Man kann nicht einmal ein Frame vernünftig erstellen, geschweige denn einen Listener, wenn man nicht weiß, dass sich Klassen erweitern lassen.


----------



## timbeau (30. Jun 2012)

Das hattest du bis jetzt aber nicht erwähnt oder?! 

Könnte das die Lösung sein:
Java ist auch eine Insel – 25.2 Sicherheitsmanager (Security Manager)

Mit einer "grant"-Datei für einzelne Klassen Rechte vergeben?


----------



## Spacerat (30. Jun 2012)

Dann sag' das doch gleich.
Das mit der Grant-Datei könnte schon mal gehen, sogar mit 'nem normalen SecurityManager (ich weigere mich, ihn SM zu nennen, solange mir dabei obskure Hintergedanken im Kopf rum schwirren. XD).
Wenn nicht, dann kommt halt der Grosse Delegator, welcher alle Methoden überschreibt, diese an einen evtl. bereits vorhandenen delegiert und erst dann die Pluginklassen prüft. Interessant dürfte dabei vor allem die Methode [c]checkMemberAccess(Class<?> clazz, int which)[/c] sein.


----------



## renwal (1. Jul 2012)

Was 
	
	
	
	





```
checkMemberAccess()
```
 mir an dieser Stelle helfen soll, verstehe ich nicht ganz. Ich habe in den Javadocs aber die Methode 
	
	
	
	





```
getClassContext()
```
 gefunden. Wenn ich das mit der Ermittlung des Speicherorts kombiniere, dann bekomme ich heraus, aus welchem Plugin der Methodenaufruf kommt, oder?


----------



## PluginSystem (2. Jul 2012)

Ich glaube eine ähnliche Diskusion gab/gibt es auch unten im Projekt-Forum Plugin-System - java-forum.org - Projekte , hier ist vor allem auch das Thema SecurityManager - java-forum.org - Projekte interessant.

Da ich allerdings auch beides verfolge (also diesen Thread und das Projekt) kommt jetzt bei mir auch die Frage auf : Warum gibt es in Java nicht die Möglichkeit z.B. einem URLClassLoader einen seperaten SecurityManager mitzugeben der dann nur für die von diesem geladenen Klassen zuständig ist ? Stattdessen gibt es nur die Möglichkeit einen VM-Instanz-globalen SecurityManager zu setzen. Und ich denke selbst wenn jetzt die gesamte Java-Community bei Oracle die Bug-Tracker bis zum glühen bringen würde so etwas wenn überhaupt erst im nächsten Major-Release kommen würde. Und da jetzt Java7 gerade mal für die Masse "freigegeben" wurde wird man darauf noch lange warten dürfen.

Man müsste die gesamte API ziemlich umbauen :

1) java.lang.ClassLoader müsste geändert werden das dieser SecurityManager verwendet. Dabei reicht es nicht dies erst in SecureClassLoader einzubauen da man ja direkt von ClassLoader ableiten kann.
2) Müsste man die gesamte API ändern das anstatt System.getSecurityManager() ClassLoader.getSecurityManager() gecallt wird. Das dürfte wohl der größte Teil der Änderung sein.
3) Zum Schluss müsste man SecurityManager selbst so ändern das es eine call-chain gibt damit gesperrte Aktionen eines "höheren" SecurityManager nicht durch einen "niedrigeren" wieder ausgehebelt werdnen können.

Ich will das jetzt nicht als "Bug" bezeichnen um den "It's not a Bug, it's a Feature"-Schreibern keine Angriffsfläche zu bieten. In meinen Augen könnte man es eher als einen ziemlichen Konzept-Fehler der gesamten SecurityManager-API bezeichnen da dies eigentlich von Anfang an hätte so implementiert werden müssen. Ich denke der Grund warum man sich eher für das Design entschieden hat nur einen "globalen" SecurityManager zu verwenden geht noch auf die Anfänge zurück als man gerade für Applets die Sandbox entwickelt hat.

Auch wenn OSGI bei sowas immer genannt wird weis ich jetzt nicht ob es dort Implementierungen gibt die ein solch umfangreiches Security-Kozept besitzen. Und das ganze selbst schreiben dürfte auch extrem aufwändig werden.

Wenn man also ein "Plugin-System" entwickelt bei dem es möglich ist das User Custom-Plugins einfügen hat man also generell das Problem der Sicherheit. Vielleicht könnte man sich mal bei Eclipse was abschauen wie dort mit den Plugins umgegangen wird. Eigentlich sollte man etwas finden.

Allgemein eigentlich ein ziemlich wichtiges Thema bei dem durch die API selbst viele Steine im Weg liegen. Vielleicht gibt es ja eine Lösung für dieses Problem. Sei es nun durch ein Framework oder durch eigenen Code. Bin persönlich selbst mal auf eine Antwort gespannt.


----------



## Spacerat (2. Jul 2012)

@PluginSystem: Ich habe mir diese beiden Links mal angesehen und muss leider sagen, du lässt dich scheinbar nur aufhalten.
Das ist mir bei meinem schon öfters erwähntem "PluginSystem" der DatatypesLibrary auch schon passiert. Hast du dir (bzw. habt ihr euch) schon mal die Frage gestellt, ob dieser "Sicherheitsfanatismus" überhaupt notwendig ist?
Mir ist da nämlich bei meiner DTLib schon relativ am Anfang aufgefallen, dass er dort relativ unangebracht war. Ich wollte die DTLib damals in Applets verwenden und Codecs (meine Plugins) on demand aus dem Internet laden lassen. Ging natürlich nicht, weil Der Sicherheitsmanager des Applets stets was dagegen hatte. Ich konnte speziell in Applets also nur Plugins verwenden, die auf dem Clienten bereits vorhanden waren. Demnach müsste der User eines Plugins dieses auch bei dir stets selbst installieren. Wenn er sich dabei schadhaften Code installiert, ist das seine Sache - ebenso, als würde man einen Crack, NoCD-Patch oder Dinge mit ähnlich viruellem Verhalten installieren.
Wenn man nun dieses PI nur mit SecurityManager starten will, genügt es die erwähnte grant-Datei zu editieren und den Standard-SecurityManager zu setzen ([c]System.setSecurityManager(new SecurityManager())[/c]). Eine eventuelle AccessControlException sollte man abfangen, denn wenn eine fliegt, ist bereits ein Manager installiert, der einem nicht gestattet, einen neuen zu setzen.
[EDIT]Aber mal ganz davon abgesehen: Dieses SecurityModell ist wirklich nicht das beste.[/EDIT]


----------



## PluginSystem (3. Jul 2012)

Lass es mich mal so formulieren :
ich selber habe ein Projekt bei dem ich Module verwende. Das ganze jetzt "PluginSystem" zu bezeichnen wäre bei mir nicht ganz zutreffen, aber es hat ähnliche Grundgedanken.
Mir ist durch aus bewusst das jemand der ein Modul entwickelt und dieses in den Module-Ordner legt damit auch quasi alles machen kann : von einer simplen "Erweiterung" über "Manipulation" bis hin zu "Schadsoftware" kann der Entwickler alles implementieren. Also mache ich mir gar nicht erst die Mühe auch nur in irgendeiner Weise zu prüfen ob das Modul von einer "vertrauenswürdigen Quelle" (von mir selbst , aus dem Entwickler-Team bzw von "vertrauenswürdigen" Dritten) oder es irgendwie in seiner Handlungsmacht einzuschränken. Denn derjenige der das System "knacken" will schafft das auch. Da kann man mit Obfuscatoren und Security-Frameworks rumspielen wie man will, denn letztendlich müssen ja "zugelassene" Module auch laufen.

Mir ist nur bei der hier vorliegenden Sachlage mal selbst aufgefallen wie "schlecht" doch eingentlich das Sicherheitskonzept von Java erdacht wurde.

Dein Beispiel mit einem Applet haut hier aber leider völlig raus, denn es dürfte dann doch einfacher sein vom Heimatserver Daten nachzuladen als zu versuchen auf irgendwelche Daten auf dem Client-Rechner zuzugreifen (was ja nun mal eh nicht geht). Damit bist du irgendwie am Ziel vorbei.

Ich habe das Wort "Applet" lediglich gebracht da dies zur Zeit der Anfänge von Java eines der größeren Hauptgebiete von Java war. Mitlerweile hat sich aber das Einsatzfeld von Java extrem verschoben und es gibt Techniken wie WebStart. Applets sind aus meiner Sicht nur noch ein Überbleibsel aus alten Tagen und heute praktisch bedeutungslos.

Auch kann ich irgendwie nicht ganz verstehen warum ihr hier so auf einem grant-File besteht. Denn dieses grant-File liegt ja auch wieder bei User und damit unter seiner Kontrolle, was völlig im Widerspruch zur Frage von TO ist welche darauf abzielt wie man dies eben aus der Anwendung herraus steuern kann um somit eine Manipulation durch den User eben zu unterdrücken.

Und "Sicherheitswahn" würde ich es nicht unbedingt nennen, aber wie ich bereits sagte : so lange die Möglichkeit besteht das ein User eigene Module/Plugins einfügen kann (wie auch immer) besteht halt die Möglichkeit der Manipulation, welche auf Grund des schlechten Security-Konzeptes von Java nicht eliminierbar ist. Zumindest nicht ohne sich wirklich ein entsprechendes Framework zu schreiben.


[ot]Leider sieht man in letzter Zeit viel zu häufig das viele "erfahrene" User mit tausenden Beiträgen offenbar nicht in der Lage sind die Probleme von neuen Usern (oder solchen die noch nicht so lange dabei sind) richtig zu erfassen. Ob es nun an der Unfähigkeit der TOs liegt das sie ihre Probleme nicht richtig beschreiben können, daran das viele die antworten sich das Problem so nicht vorstellen können da sie mit der entsprechenden Technik einfach noch kein Kontakt hatten oder schlicht an der Kommunikation untereinander kann ich leider nicht sagen. Fakt ist nur das vielen nicht geholfen wird/werden kann weil viele nicht in der Lage das eigentlich Problem was den Grund für den Thread darstellt richtig zu erfassen.
Und da muss man es einfach mal gerade heraus sagen : Wenn man keine Ahnung hat is ganz wichtig : Fresse halten !
Das ist dabei nicht so schroff gemeint wie geschrieben, aber vielleicht sollten sich auch mal die "hohen Tiere" etwas zurück halten und erstmal versuchen das Problem richtig zu verstehen anstatt blind ne Antwort zu geben die zwar aus dem selben "Gebiet" kommt aber mit dem spezifischen Problem gar nichts oder so gut wie nichts zu tun hat.[/ot]


----------



## Spacerat (3. Jul 2012)

PluginSystem hat gesagt.:


> Auch kann ich irgendwie nicht ganz verstehen warum ihr hier so auf einem grant-File besteht. Denn dieses grant-File liegt ja auch wieder bei User und damit unter seiner Kontrolle, was völlig im Widerspruch zur Frage von TO ist welche darauf abzielt wie man dies eben aus der Anwendung herraus steuern kann um somit eine Manipulation durch den User eben zu unterdrücken.
> 
> Und "Sicherheitswahn" würde ich es nicht unbedingt nennen, aber wie ich bereits sagte : so lange die Möglichkeit besteht das ein User eigene Module/Plugins einfügen kann (wie auch immer) besteht halt die Möglichkeit der Manipulation, welche auf Grund des schlechten Security-Konzeptes von Java nicht eliminierbar ist. Zumindest nicht ohne sich wirklich ein entsprechendes Framework zu schreiben.
> 
> ...


Irgendwie ist das alles recht Gegensätzlich. Einerseits verstehst du das ein oder andere nicht (z.B. den grant-File) und andererseits kritisierst du, dass andere nicht in der Lage wären, das Problem zu erfassen.
Ich erwähnte das Applet, weil mir genau dort ein SecurityManager in die Quere kam, als ich versuchte aus dem Netz (lokales Netzwerk reichte schon) geladene Datentypen verwenden zu wollen. Bis dahin war ich auch der Meinung, selber Sicherheit in mein System bringen zu müssen und siehe da, es war gar nicht nötig. Die korrekte Erfassung eines Problems hängt wohl immer ein wenig von der Erfahrung und dem daraus resultierendem Standpunkt ab.
Ich denke, ich habe das Problem reichlich erfasst, deswegen kam zunächst auch die Idee, selber einen SecurityManager entwickeln zu lassen.
Die grant-Datei (.policy) liegt auf dem Server und nur der Admin sollte sie verändern dürfen. Das macht er mit dem Policytool. Wie das genau geht, kann man in diversen Tutorials nachlesen.
Wenn man sich gegen dieses Konzept sträubt, z.B. weil es zu umständlich ist, kann man sich immer noch an die Implementation eines eigenen SecurityManagers (dass wäre dann aber wirklich SM) machen. Dabei muss man aber stets beachten, dass ein solcher bereits gesetzt wurde und evtl. zu diesem delegieren, sonst hebelt man dort bereits festgelegte Sicherheit gleich wieder aus (evtl. der Grund, warum man nur einen setzen kann). Ich habe da nicht weitergeforscht, wie das geht (weil unnötig) und [c]checkMemberAccess()[/c] war nur so 'ne Idee ins Blaue. Schliesslich wird dort ja 'ne Klasse übergeben und diese kann man auf Herz, Lunge und Nieren prüfen. Evtl. ist der ClassContext aber die weitaus bessere Idee.
[EDIT][OT]





PluginSystem hat gesagt.:


> [ot]Leider sieht man in letzter Zeit viel zu häufig das viele "erfahrene" User mit tausenden Beiträgen... siehe oben[/ot]


Solche Beiträge tragen leider noch viel weniger zur Lösung des Problems bei. Schlimmer noch; Sie könnten sie sogar verhindern, namlich genau dann, wenn genau diese "erfahrenen" Benutzer tun, was ihnen dort gesagt wurde... einfach mal die.. etcpp, anstatt sich um eine Lösung zu bemühen.[/OT][/EDIT]


----------



## FArt (3. Jul 2012)

[OT]
Posting and you - YouTube
[/OT]


----------



## renwal (3. Jul 2012)

[OT]Halloooo! Zurück zum Thema bitte! Ich denke, es hilft hier keinem weiter, über die Posting-Gewohnheiten von irgendwelchen Viel- oder Wenigschreibern zu diskutieren. Das löst das Problem nämlich auch nicht.[/OT]

Was das ursprüngliche Thema angeht: Das Grant-File ist für ein Applet vielleicht sinnvoll, aber bei einer normalen Anwendung liegt es halt auch lokal in irgendwelchen Ordnern. So kann der Anwender (oder irgendwelcher Code) es verändern, damit ist das Sicherheitskonzept ausgehebelt.
Ich werde mal die Vorgehensweise über den ClassContext ausprobieren und dann hier berichten.


----------



## timbeau (3. Jul 2012)

So wie ich das verstehe, habe ich ein System auf Vertrauensbasis bei mir installiert. Mit diesem wird das grant-file ausgeliefert und ab hier auch nicht mehr verändert. Gleiches Prinzip mit allen Virenscannern, TM-Chips etc. Schaffe ich es ein System zu kompromitieren, ist dieser Schutz natürlich hinfällig. Das Problem ist aber nicht zu lösen, siehe Root-Kits. 

Jetzt habe ich also das grant-file und lade ein Plugin von jmd dem ich NICHT zu 100% vertraue. Das grant-file muss irgendwie schreibgeschützt werden, aber daran kanns ja nicht liegen. Damit werden die Rechte des neuen Plugins eingeschränkt. Passt doch bis hier oder? 



> Auch kann ich irgendwie nicht ganz verstehen warum ihr hier so auf einem grant-File besteht. Denn dieses grant-File liegt ja auch wieder bei User und damit unter seiner Kontrolle, was völlig im Widerspruch zur Frage von TO ist welche darauf abzielt wie man dies eben aus der Anwendung herraus steuern kann um somit eine Manipulation durch den User eben zu unterdrücken.



Das halte ich für eine Fehleinschätzung des grant-files. Wenn ich mir einen Virenscanner installiere und diesen eigenhändig manipuliere funktioniert dieser nicht mehr, klar. Aber das ist nicht das Problem. 
[OT]Im übrigen ist deine Ausdrucksweise typisch für Gäste & nicht hilfreich[/OT]


----------



## renwal (3. Jul 2012)

Da habt ihr natürlich Recht. Ich wollte das System halt möglich "idiotensicher" machen. Aber mal nebenbei: Wie bekommt man einen SecurityManager via Grant-File überhaupt gesetzt, wenn nicht über einen VM-Parameter? Das geht ja nicht, sonst klickt einer die jar-Datei, die die Haupt-Anwendung enthält, an und das ganze läuft ohne SecurityManager.


----------



## Spacerat (3. Jul 2012)

renwal hat gesagt.:


> Wie bekommt man einen SecurityManager via Grant-File überhaupt gesetzt, wenn nicht über einen VM-Parameter? Das geht ja nicht, sonst klickt einer die jar-Datei, die die Haupt-Anwendung enthält, an und das ganze läuft ohne SecurityManager.


Das habe ich schon weiter oben gepostet.

```
class MySecurityClass {
  public static void main(String args) {
    try {
      System.setSecurityManager(new SecurityManager());
    } catch(AccessControlException e) {
      // nothing
      // already set
    }
  }
}
```
Das setzt den standard SecMan, sinnigerweise ganz am Anfang der Anwendung. Deine PIs kommen dort wohl nicht dran vorbei. Die Exception kann auch nur kommen, wenn der SecMan per Parameter gesetzt wurde.


----------



## renwal (3. Jul 2012)

Und woher weiß der SecurityManager dann, wo das Grant-File liegt?


----------



## timbeau (3. Jul 2012)

Hilft dir das :JavaBlogging  Using Java SecurityManager to grant/deny access to system functions


----------



## renwal (3. Jul 2012)

Das hilft insofern, dass es die Syntax von Policy-Files etwas näher erläutert. Aber es sagt mir immer noch nicht, wie ich denn dem SecurityManager jetzt diese Datei zuweise, ohne die Kommandozeile benutzen zu müssen. Ein jar-Archiv enthält doch die Parameter nicht mehr, die ich wie angegeben in Eclipse in die Run Configuration eintrage, oder?


----------



## Spacerat (3. Jul 2012)

Holy shit... (Im Sinne von: "Ach herrje, das weis ich jetzt auch nicht. Vllt. hätt' ich die Fr... halten sollen." )
timbeaus Post gilt nur für die Parameter-Methode. Ich hab's nicht weiter vertieft, aber ich nehme mal an, dass der StdSecMan die Datei [c]%JAVA_HOME%/lib/security/java.policy[/c] lädt.
Für die "Nachhol-Methode" in der Main hat man anscheinend sonst keine Möglichkeit eine andere Datei zu laden.
Wie gesagt: Es liegt immer noch die Frage im Raum, ob Sicherheit überhaupt Sache des Pluginsystems oder vielmehr Sache der Anwendung ist, die es benutzt. Für meine DTLib ist es einfach, es ist Sache der Anwendung und dass ich selbst eine SecMan dafür entwickeln musste, erwies sich als Irrtum. Plugins (Codecs) werden von Usern ebenso wie DLLs oder SOs auf eigene Gefahr installiert und verwendet. Die jeweilige Anwendung bestimmt nun mit ihrem SicherheitsManager, welche Dateien woher geladen bzw. wohin gespeichert werden dürfen (Bei Applets ausschliesslich die DocumentBase) und verhindert die ungewollte, unauthorisierte Einschleusung fremder PlugIns.


----------



## timbeau (3. Jul 2012)

Also ein jar mit vm Argumenten zu starten ist dann das nächste Problem....

Die Schwierigkeiten werden irgendwie nicht weniger ^^


----------



## renwal (3. Jul 2012)

Okay, kurze Zusammenfassung:

Dass das mit den VM-Argumenten über die Kommandozeile nicht geht, habe ich vorher schon geschrieben, das war also nichts neues (#17).

Wegen der Sicherheitsfrage und ob sich der Aufwand überhaupt lohnt: Es geht mir auch weniger darum, dass irgendein Entwickler Schadcode implementiert, als um die Tatsache, dass ich auch nicht will, dass diese Plugins irgendwelche Threads anlegen und damit den Kontrollmechanismus lahmlegen.
Sobald ein Thread erstellt ist, kann ich ihn vom PluginManager aus nicht mehr kontrollieren, geschweige denn beenden. Wenn das dann ein User-Thread und kein Daemon-Threas ist, dann habe ich ganz schnell das Problem, dass die VM nicht beendet wird, wenn dieser Thread noch aktiv ist.
Stattdessen sollen die Entwickler über das Interface einen Thread aus dem Thread-Pool zugewiesen bekommen, der dann aber kontrollierbar bleibt, da ich Zugriff auf die Instanz habe. Der SecurityManager sorgt in erster Linie also dafür, dass die Vorgaben eingehalten werden, da ich kaum jedes Plugin sebst prüfen kann.


----------



## timbeau (3. Jul 2012)

Das es nicht geht stimmt aber nicht. 

Dafür gibts glaube ich JNLP


----------



## Spacerat (3. Jul 2012)

Wo bitte läuft eigentlich die Anwendung? Wie und von wem sollen Plugins hinzugefügt werden können? Was sollen diese Plugins denn machen? Der, der die Anwendung startet, trägt auch die Verantwortung der (eigenen) Sicherheit und im Prinzip auch die, welche Plugins installiert wurden.
Evtl. bietet ja ein ServletContainer wie z.B. Tomcat die gewünschte Funktionalität, hier kann man zumindest Rechte pro Servlet zuweisen.
Als letzte Möglichkeit kannst du ja per Jasper zu installierende PIs darauf prüfen, was sie machen (z.B. auf [c]<Thread>.start()[/c] etc).


----------



## Lumaraf (3. Jul 2012)

renwal hat gesagt.:


> Sobald ein Thread erstellt ist, kann ich ihn vom PluginManager aus nicht mehr kontrollieren, geschweige denn beenden. Wenn das dann ein User-Thread und kein Daemon-Threas ist, dann habe ich ganz schnell das Problem, dass die VM nicht beendet wird, wenn dieser Thread noch aktiv ist.
> Stattdessen sollen die Entwickler über das Interface einen Thread aus dem Thread-Pool zugewiesen bekommen, der dann aber kontrollierbar bleibt, da ich Zugriff auf die Instanz habe. Der SecurityManager sorgt in erster Linie also dafür, dass die Vorgaben eingehalten werden, da ich kaum jedes Plugin sebst prüfen kann.



Schau dir mal die Klasse 
	
	
	
	





```
java.lang.ThreadGroup
```
 an. Für dich dürfte speziell von interesse sein das es nicht möglich ist eine neue ThreadGroup zu erstellen die keiner anderen vorher existierenden untergeordnet ist. Darüber kannst du alle Threads die irgendwo erstellt werden von einer ThreadGroup abfragen.


----------



## renwal (4. Jul 2012)

Spacerat hat gesagt.:


> Wo bitte läuft eigentlich die Anwendung? Wie und von wem sollen Plugins hinzugefügt werden können? Was sollen diese Plugins denn machen? Der, der die Anwendung startet, trägt auch die Verantwortung der (eigenen) Sicherheit und im Prinzip auch die, welche Plugins installiert wurden.
> Evtl. bietet ja ein ServletContainer wie z.B. Tomcat die gewünschte Funktionalität, hier kann man zumindest Rechte pro Servlet zuweisen.
> Als letzte Möglichkeit kannst du ja per Jasper zu installierende PIs darauf prüfen, was sie machen (z.B. auf [c]<Thread>.start()[/c] etc).


Die Anwendung ist ein jar, das _lokal_ auf irgendeinem Rechner läuft.

Plugins kann theoretisch _jeder_ erstellen, der Java kann. Einige sind über einen _Plugin Store_ verfügbar, andere, die von Dritten entwickelt worden sind, werden _per Datei_ hinzugefügt. Jedes Plugin besteht aus einem einzelnen jar-Archiv und einem Ordner, in dem es seine Dateien verwalten kann.

Ein solches Plugin kann Funktionen des Programms erweitern. Über die manifest-Datei gibt es an, was es zur Ausführung benötigt. Die Schnittstelle, d.h. der PluginManager der Hauptanwendung ermöglicht dem Plugin den Zugriff auf Dateien und stellt bei Bedarf einen Thread-Pool bereit.
Die Erweiterung des Programms kann so aussehen, dass das Plugin einfach ein neues Fenster erzeugt, in dem es seine Inhalte anzeigt, oder aber so, dass das Plugin die Hauptanwendung anweist, an bestimmten Stellen im UI Komponenten einzufügen.



timbeau hat gesagt.:


> Das es nicht geht stimmt aber nicht.
> 
> Dafür gibts glaube ich JNLP


Mit "geht nicht" meinte ich halt, dass das praktisch nicht umsetzbar ist, solange die Anwendung lokal läuft. WebStart ist in diesem Fall mMn nicht wirklich das optimale Ergebnis.


----------



## Spacerat (4. Jul 2012)

renwal hat gesagt.:


> Die Anwendung ist ein jar, das _lokal_ auf irgendeinem Rechner läuft.


Na prächtig... Dann musst du dir um die Sicherheit gar keine Gedanken machen, dass ist Sache der Anwendung. Nur über die Funktion, wie Plugins installiert/entfernt werden können ist deine Sache. Hier darfst du auch durchaus hin und wieder mal [c]AccessController.doPrivileged()[/c] verwenden. Der User dieser Anwendung installiert PlugIns auf eigene Gefahr oder hat selbst einen SecurityManager installiert. Bei meiner DTLib ist es nicht anders.

Das Verfahren ist simpel. Es können nur PlugIns installiert werden, die der User explizit auswählt. Diese Auswahl trifft er Aufgrund seiner Entscheidung. Für die bestmögliche Lauffähigkeit ist weder der User noch Der PM sondern der Entwickler des PlugIns verantwortlich. Wenn ein PlugIn nicht wie geplant läuft, sendet man einen BugReport. Ist man der Meinung, dass ein PI schadhaften Code enthält, lässt man es prüfen (Links dazu gibt es auf sehr vielen Seiten, wo man Virensoftware bekommt) und deinstalliert es. Sicher kennst du schon den ein oder anderen Disclaimer/Haftungsausschluss


----------



## renwal (7. Jul 2012)

Ja, ja. Schön aus der Verantwortung ziehen.
Eigentlich war nicht das Ziel, das Ganze mit dem Vermerk "Sind Sie ja schuld, wir haben doch gesagt, sie müssen aufpassen" abzutun.


----------



## Spacerat (7. Jul 2012)

Deine Intension in alle Ehren. Im Moment sieht's dann ja wohl so aus, als würde sich die halbe Welt aus der Verantwortung ziehen. Aber das ist bei weitem nicht so, ich denke nicht, dass du trotz automatischem Sicherheitsmanager auf diesen Haftungsausschluss verzichten könntest, denn wenn er fehlt, schafft's ein PI-Entwickler wo möglich trotzdem und du stündest dann mit einem User dieses PIs vor Gericht, weil es Schaden gemacht hat. Schaden, den du bisher nicht verhindern konntest und dies auch in Zukunft nicht könntest (geh' davon aus). Geh dann weiter davon aus, dass ernst zu nehmende Software auch genau so entwickelt, sowie vertrieben wird. Wer wissentlich schadhaften Code oder als solchen identifizierten in seine Anwendungen und PIs implementiert, wird schnell merken, dass er die Software nicht los wird.

Und falls du nun noch der Meinung bist, dass deine Software unbedingt mit Sicherheitsmanager starten sollte, genügt es, diesen beim Start in der Main gegen Null zu prüfen und entweder mit einer entsprechenden Exception ("Bitte starten sie die Anwendung über das beigefügte Script") abzubrechen oder eine Art SelfRestartWithManager durchzuführen. Letzteres ist ein Mechanismus, den ich selber auch gerne sicher hinbekommen würde.


----------



## Lumaraf (7. Jul 2012)

Mit dem folgenden Code kann man den SecurityManager auch mit einem bestimmten Policy-File initialisieren.


```
File policyFile=new File(...);
System.setProperty("java.security.policy", policyFile.getAbsolutePath());
System.setSecurityManager(new SecurityManager());
```


----------



## Spacerat (7. Jul 2012)

Das wusste ich auch noch nicht, dafür mal 'n Danke.


----------



## renwal (10. Jul 2012)

Ich kann das zwar frühestens in zwei Wochen ausprobieren, eher in drei, aber schon einmal Danke im Voraus!


----------



## renwal (6. Aug 2012)

Super, vielen Dank! Es klappt einwandfrei! Mit der CodeBase-Funktion kann man ja so super einstellen, was das Plugin alles können soll. :toll:

Eine Frage hätte ich aber noch: Warum erhalte ich bei folgender Situation eine AccessControlException?

Das Programm prüft die Existenz einer Datei in Pfad 2. Im Grant-File ist nun entweder die Berechtigung für Pfad 1 (-> Exception) oder Pfad 2 (-> funktioniert) gesetzt.

Pfad 1:

```
C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\slernV2\*
```

Pfad 2:

```
C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\slernV2\profiles\*
```

Schließt das \* in Pfad 1 nicht auch alle Unterordner (und damit Pfad 2) mit ein?


----------



## Tomate_Salat (6. Aug 2012)

Interessantes Thema.

Spontan hab ich mal folgendes gestest:

```
public class Test 
{
	public static void main(String[] args) 
	{
		MySecure.init();
		
		test();
		
		ThreadGroup plugin=new ThreadGroup("plugin");
		Thread th=new Thread(plugin, "plugin-0") {
			@Override
			public void run() {
				test();
				ThreadGroup hackIt=new ThreadGroup("hackit!");
				new Thread(hackIt,"hack-0") {
					@Override
					public void run() {
						test();
					}
				}.run();
			}
		};
		th.start();
	}
	
	static void test()
	{
		try {
			Runtime.getRuntime().exec("cmd");
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

class MySecure extends SecurityManager
{
	public static void init()
	{
		System.setSecurityManager(new MySecure());		
	}	
	
	@Override
	public void checkExec(String cmd) 
	{
		System.out.println(getThreadGroup().getName());
	}
}
```

Ausgabe:

```
main
plugin
plugin
```

D.h. über die ThreadGroup könnte man theoretisch wirklich Zugriffsrechte Definieren. Je nachdem in welcher Gruppe ein Plugin gestartet wird, erhält es entsprechende rechte.


----------



## renwal (6. Aug 2012)

Könnte man, aber für mein Beispiel ist das gar nicht notwendig. Da jedes Plugin sowieso ein eigenes jar hat, geht es einfacher über die Bestimmung der CodeBases. Dann die Berechtigung zum Schreiben in den Ordner, der die Plugins enthält, entziehen, damit die Plugins sich nicht durch Umbenennen mehr Rechte verschaffen können und fertig das ganze.


----------



## renwal (8. Aug 2012)

Habe das Problem mit den Berechtigungen gerade selbst gelöst. Wenn man die Docs aufmerksam liest, stellt man nämlich fest, dass der rekursive Zugriff auf alle Ordner unter dem Pfad der Berechtigung nicht mit 
	
	
	
	





```
...\*
```
 sondern mit 
	
	
	
	





```
...\-
```
 gegeben wird. Kaum macht man es so, geht es auch.

LG René


----------



## Lumaraf (8. Aug 2012)

renwal hat gesagt.:


> Habe das Problem mit den Berechtigungen gerade selbst gelöst. Wenn man die Docs aufmerksam liest, stellt man nämlich fest, dass der rekursive Zugriff auf alle Ordner unter dem Pfad der Berechtigung nicht mit
> 
> 
> 
> ...



Der .../* erlaubt nur den Zugriff auf alle Dateien in dem Ordner. Mit .../- erlaubt man auch den Zugriff auf Unterordner.


----------

