Projektstudium SS98 - distributed computing


vorherige SeiteInhaltnächste Seite

Sicherheitspolitik

Nach dem wir die Permissions genauer betrachtet haben kommen wir nun zu der Sicherheitspolitik. Hier ist es gerade wichtig zu Prüfen in wie weit das Konzept im Anwendungsfall handbar ist.

 

Die Systemsicherheitspolitik für das Java runtime system ist durch ein Permission Objekt abgebildet. Dies hat zur Folge, das ein Applet (oder eine Anwendung, die unter der Aufsicht eines Sicherheitsmanager läuft) die Permission zum Lesen oder Schreiben von Dateien erteilt erlaubt sein muß, damit es diese Aktion durchführen kann.

 

Die aktuelle installierte Politik kann abgefragt werden über die Methode getPolicy() und geändert werden über die Methode setPolicy().

 

Das PolicyObjekt bewertet die globale Sicherheitspolitik und gibt ein passendes PermissionObjekt zurück, welches die Permission spezifiziert die für den entsprechenden Code erlaubt sind.

 

Die Sicherheitspolitik kann in jeglicher Form gespeichert werden, das heißt als ASCII-Datei, Binärdatei oder aber auch Datenbank. Es existiert eine standard Politik Implementation, die ihre Daten aus einer statischen policy Konfigurationsdatei erhält.

 

Wie ist das Policy Dateiformat?

 

In der standard Implementierung kann die policy in einen oder mehrere policy Dateien definiert werden. Die Konfigurationsdateien spezifizieren, welche Permissions für welchen Code erlaubt sind. (Der Code wird auf Grund seines Herkunftsortes unterschieden.) Im wesentlichen enthält eine Konfigurationsdatei eine Liste von Einträgen.

 

Mit dem folgenden Eintrag wird festgelegt wo die Schlüssel für Signaturen abgespeichert werden:

 

keystore "eine_keystore_url"

 

Wo "eine_keystore_url" die URL definiert, die den Ort des keystores angibt. Die URL is relativ zur policy Datei.

 

Jeder grand Eintrag in einen Policy file besteht aus der CodeSource und seine Permissions. Er hat folgendes Format:

 

grant [SignedBy "signer_names"] [, CodeBase "URL"] {

permission permission_class_name [ "target_name" ]

[, "action"] [, SignedBy "signer_names"];

permission ...

};

 

 

Die Reihenfolge der CodeBases und SignedBy Felder wird nicht berücksichtigt.

Im folgenden wird noch die Syntax eine Policy Datei in BNF angegeben:

 

PolicyFile -> PolicyEntry | PolicyEntry; PolicyFile

PolicyEntry -> grant {PermissionEntry}; |

grant SignerEntry {PermissionEntry} |

grant CodebaseEntry {PermissionEntry} |

grant SignerEntry, CodebaseEntry {PermissionEntry} |

grant CodebaseEntry, SignerEntry {PermissionEntry} |

keystore "url"

SignerEntry -> signedby (a comma-separated list of strings)

CodebaseEntry -> codebase (a string representation of a URL)

PermissionEntry -> OnePermission | OnePermission PermissionEntry

OnePermission -> permission permission_class_name

[ "target_name" ] [, "action_list"]

[, SignerEntry];

 

Nun sehen wir noch einige Beispiele:

 

Die folgende policy grants permission a.b.Foo für code signed von Roland:

 

grant signedBy "Roland" {

permission a.b.Foo;

};

 

Das Folgende grants eine FilePermission für jeglichen code:

 

grant {

permission java.io.FilePermission ".tmp", "read";

};

 

Das Folgende grants zwei permissions für den Code, der von Li and Roland von signed wurde:

 

grant signedBy "Roland,Li" {

permission java.io.FilePermission "/tmp/*", "read";

permission java.util.PropertyPermission "user.*";

};

 

vorherige SeiteInhaltnach obennächste Seite 


© Copyright 1998 André Möller, Oliver Mentz & Magnus Wiencke