Sinn des Security Managers

[Plunty]

Hallo Zusammen,

ich habe eine Verständnisfrage zum Security Manager(SM) von Java Applikation (keine Applets).

Wen soll dieser eigentlich schützen?
Der SM muss ja extra vom Programmierer im Quellcode gestartet werden und er kann auch die Rechte in einer eigenen Policy - Datei festlegen... hat er vor ein schädliches Programm zu schreiben wird er das nicht machen und ansonsten braucht mans ja nicht? Was ist also Sinn und Zweck der Geschichte?

Bei Google steht dann über den Security Manager immer nur dass man ihn setzten kann, dass man damit Rechte vergibt und wie das alles geht aber irgendwie nie ohne verständliches Beispiel wann er Sinn macht... Da steht z.B. dass man es bei RMI aufm Server setzten kann um Clients nicht falsche Methoden ausführen zu lassen aber die Methoden die über RMI angesprochen werden dürfen sind ja eh durchs Interface beschränkt oder etwa nicht? Also wenn des jemand mal einfach verständlich erklären kann wär ich ihm sehr dankbar


Gruß Plunty

 

[SlaterB]

der klassische Einsatz scheinen mir die Applets zu sein:
es gibt eine laufende Java-Umgebung im Browser, die zusätzliche beliebige Klassen lädt und ausführt,
da muss man aufpassen was dieser Code macht, es wird eine Sandbox bereit gestellt, kritische Befehle wie Festplattenzugriff verhindert,

bei dem RMI-Beispiel ist vielleicht an Übertragung von ganzen Klassen an den Server gedacht mit dann ähnlicher Situation,
statt Interface-Aufrufen wird beliebiger neuer Code ausgeführt

1.2.5 Sicherheit

----

Wiki :: tasin/RMITutorial2

Solange die Server- oder Clientapplikation keinen Code von einem entfernten Rechner nachladen soll, ist kein Securitymanager nötig.

----

aber auch bei eigenen Programmen, die eigentlich nur in geeigneten Bahnen laufen sollen, kann es Sinn machen, zur Sicherheit die Rechte einzuschränken,
da bietet man einen JFileChooser zur Auswahl einer Textdatei an, und der kann glatt neue Verzeichnisse erstellen oder umbenennen oder löschen, hat man daran genau gedacht?

wenn man irgendeinen kleinen dynamischen ClassLoader eigentlich nur für eigene Plugins wie Look & Feels der GUI hat,
dazu eine Upload-Funktionalität, eigentlich nur für Dateien wie z.B. hier im Forum Posting-Anhänge,
und es ein User doch durch geschickte Dateipfade schafft, eine .class-Datei in das Plugin-Verzeichnis zu schieben (und auch zu starten),
dann kann damit vielleicht eigener Code zur Ausführung gebracht werden mit allen möglichen Folgen,
dann ist ein laufender Security-Manager doch ganz nett, falls er hilft

oder Klassen aus einer DB geladen, auf deren Tabellen ein User 'eigentlich' keinen Zugriff haben sollte aber es doch irgendwie schafft, SQL bietet ja manche Tricks

----

bei vorliegenden Quellcode und eigenen Start ist Security natürlich abschaltbar soweit bekannt, genau wie Passwörter usw.,
es geht hauptsächlich um laufende geschützte Programm und deren offene Eingangstüren

 

[maki]

Wen soll dieser eigentlich schützen?
Der SM muss ja extra vom Programmierer im Quellcode gestartet werden und er kann auch die Rechte in einer eigenen Policy - Datei festlegen... hat er vor ein schädliches Programm zu schreiben wird er das nicht machen und ansonsten braucht mans ja nicht? Was ist also Sinn und Zweck der Geschichte?

Nö, der SM kann auch deklerativ konfiguriert werden wie es zB. bei ServletContainern(Tomcat) und AppServern(GlassFish, etc. pp.) der Fall ist.
Damit kann man zB. verschiedene Anwendungen von verschiedenen Herstellern auf einem Server laufen lassen und sicherstellen dass sich alle Anwendungen "nett" verhalten, "nett" reicht dabei von Sicherheit bis zu dem Fall in dem eine App der Meinung ist sie müsste ein System.exit aufrufen.