Java – Sicherheits – Dateien - Weblearn

Hochschule Bremen
JDK 1.x
Java – Security - Modell
Veranstaltung
Security SS `99
Dozent
Prof. Dr. Th. Risse
Datum
18. Mai 1999
Autor
Catrin Godau
Semester
I8I1
Security / Java-Sicherheit
Catrin Godau
Java – Sicherheitsmodelle ................................................................................................................... 3
ClassLoader ..................................................................................................................................... 5
Bytecode-Verifikation ....................................................................................................................... 5
Das neue Sicherheitsmodell des JDK 1.2 ........................................................................................... 6
Sicherheit in Applets ............................................................................................................................ 8
Appletviewer, Java-Plug-In .............................................................................................................. 9
Internet Explorer ............................................................................................................................... 9
Netscape Communicator .................................................................................................................. 9
Beispiel für die Nutzung des SecurityManager .................................................................................. 11
Mit dem JDK1.2 jar.exe ein neues Jar-File erstellen: .................................................................... 13
Mit dem JDK 1.2 keytool.exe eine neue .keystore - Datei erzeugen: ................................................ 14
Mit dem JDK1.2 jarsigner.exe aus der mit jar.exe erzeugten jar-Datei eine signierte jar-Datei
erstellen:............................................................................................................................................. 17
Java – Sicherheits – Dateien / ........................................................................................................... 19
Policy - Datei ...................................................................................................................................... 20
Benutzung des Policy Tools: .......................................................................................................... 20
Listing des Beispiel-Applets ............................................................................................................... 24
Einbinden der signierten und unsignierten Applet-Klassen in eine HTML Seite, die auf irgendeiner
WebPage verfügbar ist: ..................................................................................................................... 28
Quellen ............................................................................................................................................... 29
2
Java – Sicherheitsmodelle
Einer der Aspekte, mit denen für Java als Programmiersprache geworben wird ist, daß
Java eine „sichere“ Sprache sein soll. Das ist aufgrund der verteilten Natur von Java auch
besonders wichtig, denn ohne ein gewisses Maß an Sicherheit würde sich wohl kein
vernünftiger Anwender unbekannten Programmcode von einer Website herunterladen und
auf dem eigenen Rechner laufen lassen. Ob eine Anwendung als bösartig angesehen
wird, hängt primär davon ab, ob sie als Applikation oder als Applet läuft. Applikationen
werden als sicher angesehen und haben volle Rechte, während Applets als nicht
vertrauenswürdiger Code angesehen werden. Auf fast jeder Website laufen mittlerweile
Java-Applets. Diese müssen vom Netz heruntergeladen und auf dem eigenen Rechner
ausgeführt werden. Java stellt Mechanismen für solche Sicherheitsbelange zur
Verfügung. Es werden verschiedene Sicherheitsstufen in den verschiedenen JDKVersionen bereitgestellt die vor sogenanntem bösartigem Code schützen sollen:

Java-Programme können keine Zeiger auf den Arbeitsspeicher anlegen, oder Arrays
über die Array- oder String- Grenzen hinaus lesen. Dadurch, daß der Zugriff auf den
Speicher damit völlig unterbunden wird, wird ein großer Teil von Sicherheitsattacken
vollständig unterbunden.

Der Java-Interpreter führt bei jedem unbekannten Code eine Überprüfung des ByteCodes durch. Dadurch wird sichergestellt, daß der Code richtig geformt ist. D.h., daß
der keine illegalen Byte-Codes enthält, oder einen Unterlauf des Stacks verursacht.
Somit wird ausgeschlossen, daß Implementierungslücken des Interpreters ausgenutzt
werden.

Eine weiter Sicherheitsschicht stellt das sogenannte Sandbox-Modell dar. Der
unbekannte Programmcode (Applet) wird quasi in einer Art Sandkasten plaziert, in
dem er sicher „spielen“ kann, ohne der realen Welt (Ausführungs-Umgebung)
Schaden zufügen zu können
. In dieser Sandbox gelten eine Reihe von Einschränkungen:
 keinerlei Zugriff auf das lokale Dateisystem,
 kein Herstellen von Netzwerkverbindungen,
 etc.

3
Security / Java-Sicherheit
Catrin Godau
Die Security-Beschränkungen werden von der Java-Klasse SecurityManager
umgesetzt. Alle Java-Kernklassen, die sensitive Operationen durchführen (Dateizugriff,
4
etc.) fragen zuerst den SecurityManager um Erlaubnis, ob die jeweils angeforderte
Operation durchgeführt werden darf. Erfolgt ein solcher Aufruf direkt oder indirekt durch
unbekannten Code, generiert der SecurityManager eine SecurityException und die
Operation wird nicht erlaubt.
Das Sicherheitsmodell des JDK 1.0.x wird noch vom Alles-oder-Nichts-Prinzip
(Alle Rechte oder keine) geprägt. Es ist hier von der Laufzeitumgebung nur die
Entscheidung zu fällen, ob ein heruntergeladenes Applet als vertrauenswürdig eingestuft
wird oder nicht. Erscheint es vertrauenswürdig, bekommt es alle Rechte, wird es als nicht
vertrauenswürdig eingestuft, bekommt es keinerlei Rechte. Ein feines granulierbares,
individuell anpaßbares Sicherheitsmodell ist mit diesem SecurityManager nicht möglich.
Ebenfalls unterliegt die Ausführung auf dem Host ausgeführten Codes nicht der Kontrolle
dieses SecurityManagers. Das JDK 1.0x umfaßt aber bereits den Bytecode-Verifier und
den Applet-Class-Loader.
ClassLoader
Ein weiterer wichtiger Bestandteil der Java-Sicherheit, ist die Art und Weise, wie Java
Klassen über das Netzwerk lädt. Wie das geschieht, wird in der Klasse
java.lang.ClassLoader definiert. Appletviewer und Browser legen Subklassen von
dieser Klasse an, um zu definieren, wie Klassendateien über verschiedene Protokolle
geladen werden dürfen. Eine der wichtigen Funktion des ClassLoaders besteht darin,
sicherzustellen, daß die geladenen Klassen in einem anderen Namensraum liegen als die
vom lokalen System geladenen Klassen. Auf diese Weise werden Namenskonflikte
vermieden und gleichzeitig verhindert, daß ein böswilliges Applet Java-Standardklassen
durch eigene Versionen ersetzt. Der ClassLoader ist ebenfalls dafür zuständig, das der
über das Netzwerk geladene Bytecode an den Bytecode-Verifier zur Überprüfung
übergeben wird.
Bytecode-Verifikation
Dieser Prozeß stellt sicher, daß der Code nicht die Namens- und
Typumwandlungsbeschränkungen von Java verletzt. Er stellt ebenfalls sicher, daß der
Code die folgenden Bedingungen erfüllt:

Es muß sich um gültigen Code der Java Virtual Machine handeln,der

keinen Über- Unterlauf des Stacks verursacht,

Register nicht inkorrekt verwendet und

keine illegalen Datenkonvertierungen durchführt.

...
Ab dem JDK 1.1.x werden sogenannte signierte Applets eingeführt. Der
Programmierer hat damit die Möglichkeit, seine Applets mit einer digitalen Signatur
zu versehen, die dann vom Security-Manager überprüfbar ist. So kann die Herkunft des
Codes kryptografisch gesichert und fälschungssicher bestimmt werden. Wenn man
angibt, daß man einer bestimmten „Quelle“ (Person, Firma, etc.) vertraut, können die
Applets dieser Quellen außerhalb der Sandbox-Umgebung ausgeführt werden. Applets
mit einer solchen Signatur können damit die gleichen Rechte eingeräumt werden wie
lokalen Applikationen, sofern die zugehörige digitale Unterschrift des Applets akzeptiert
wurde. Appletts ohne digitale Unterschrift bleiben weiterhin in der Sandbox-Umgebung
gefangen und haben keine lokalen Berechtigungen. Die Zuteilung der Rechte erfolgt im
JDK 1.1 jedoch weiterhin binär, d.h. es können einem Applet entweder alle Rechte oder
keine Rechte zugeteilt werden. Das hat sich ebenfalls als unflexibel und für die
professionelle Praxis noch als unzureichend erwiesen.
5
Security / Java-Sicherheit
Catrin Godau
Das neue Sicherheitsmodell des JDK 1.2
Das neue Sicherheitsmodell des JDK 1.2 beruht auf sogenannten Policies. Ab dem JDK
1.2 können Applets entweder nach Herkunftsort (Codebase) oder nach Urheber
(Signierer) differenzierte Rechte zugeteilt werden. Dadurch kann einem Applet der Zugriff
auf eine bestimmte lokale Datei gewährt werden, während er einem anderen verwehrt
wird. Dadurch können Rechte jetzt sehr gezielt vergeben werden.
Diese Rechte werden in Policy-Dateien gespeichert. Das JDK 1.2 enthält eine sogenannte
System-Policy-Datei (<JAVA_HOME>/jre/lib/security/java.policy)1, in der die
Grundeinstellungen gespeichert sind. Jeder Benutzer hat die Möglichkeit eine eigene
private Policy-Datei zu erstellen. Diese Datei muß im Home-Verzeichnis des Benutzers
abgelegt werden. Die Policy-Datei kann mit jedem beliebigen ASCII-Editor geändert
werden. Einfacher ist es aber, wenn das von Sun mitgelieferte Tool policytool
verwendet wird. Damit lassen sich Policy-Dateien laden, verändern und an gewünschtem
Ort abspeichern. Ebenfalls ist es nicht nötig die Syntax der Grant-Befehle zu kennen. Die
Codebase wird durch eine URL, der Signierer durch den Alias in der lokalen Public-KeyDatenbank angegeben.
Zwar konnte man schon immer Unterklassen des Security-Managers2 bilden und somit
dessen Verhalten auf die eigenen Belange abändern. Diese Vorgehensweise besaß aber
zwei Nachteile: Zum einen lag darin die Gefahr, potentielle Angriffspunkte nach Außen zu
bieten, zum anderen implementierten die Browser-Hersteller eigene Security-Manager
womit der Applet-Entwickler wieder in seine Schranken gewiesen wurde. Damit blieb das
ursprüngliche Modell zu restriktiv für Applets und bot lokalen Applikationen viel zu großen
Freiraum.
Ab dem JDK 1.2 soll jede Klasse ihre eigenständigen Rechte besitzen. Auch die
Verknüpfung lokaler Dateien mit Java-Klassen soll individuell möglich sein. Deshalb
wurden sogenannte Protection-Domains eingeführt und die Funktionalität des ClassLoaders um einige Aufgaben erweitert. Über Protection-Domains kann ein Client ganz
genau festlegen, welche Ressourcen einem Applet oder einer Applikation mit welchen
Berechtigungen
zur
Verfügung
stehen.
Applets
müssen
also
ihre
Sicherheitsbestimmungen nicht mehr mitbringen (im Quellcode des Applets eincodiert),
sondern laufen jetzt mit den Rechten, die vom lokalen Rechner bestimmt werden. Im
neuen Sicherheitsmodell des JDK 1.2 gehört jede Klasse zu genau einer ProtectionDomain. Eine Protection-Domain kann von mehreren Klassen gleichzeitig genutzt werden.
Damit können heruntergeladene Applets auf vorher definierte Ressourcen zugreifen; d.h,
die Sandbox wird jetzt nach den lokal vergebenen Sicherheitsvorkehrungen geöffnet. Der
Zugriff auf lokale Ressourcen kann damit auch für lokale Applikationen eingeschränkt
werden. Dieser Sicherheits-Mechanismus wird vom Security-Class-Loader umgesetzt. Es
ist nicht mehr der gesamte Bereich der JVM zugänglich, sondern nur eingeschränkte vom
Security-Class-Loader freigegebene Bereiche.
Die Elemente des eigentlichen
Sicherheitsmechanismus werden jetzt außerhalb der JVM verwaltet.
Protection-Domains werden in zwei Kategorien eingeteilt: System-Domains und
Applikation-Domains. Zu den System-Domains gehöhren alle Systemressourcen wie FileIO, Maus, Keyboard oder Netzwerkzugriff. Zu den Applikation-Domains gehören alle
spezifischen Ressourcen einer Applikation.
In der Regel will eine Anwendung auf Ressourcen zugreifen, die zu beiden Kategorien
gehören, weil an einer Ausführungseinheit des Java-Bytecodes typischerweise mehrere
Klassen beteiligt sind, und so meistens auch mehr als eine Protection-Domain betroffen
ist. Die Menge der jeweiligen Rechte beim Überqueren der Grenzen muß mit den
vorgegebenen Berechtigungen übereinstimmen. Die Überwachung übernimmt das JRE.
Eine Anwendung aus einem unkritischen Bereich darf nicht plötzlich über mehr
Berechtigungen verfügen, nur weil der Aufrufer einer Methode über mehr Berechtigungen
verfügt.
Zu den neuen Security-Utilities des JDK 1.2 gehören die Programme policytool und
keytool, sowie der jarsigner. Mit dem policytool-Utility können Sicherheitskriterien
festgelegt werden. Es können damit die Dateien java.policy und java.security
1
2
Datei-Ausdruck im Anhang
Beispiel im Anhang
6
editiert werden. Mit dem keytool-Utility lassen sich Zertifikate und Aliases verwalten.
Dieses Utility arbeitet mit der Datei .keystore, die sich im Java-Home-Verzeichnis
befindet. Diese Datei existiert erst nachdem sie mit diesem Utility erzeugt wurde. In der
Datei befinden sich verschlüsselte Einträge eingerichteter Zertifikate mit zugehörigem
Alias. Ein dort eingetragener Alias wird vom signedBy-Feld der Policy-Datei verwendet.
Er repräsentiert dabei ein Objekt, das Code unterschreiben kann. Der jarsigner ist ein
Utility, mit dem jar-Dateien signiert werden können. Dazu kommen Informationen aus
dem .keystore-File zum Einsatz. Die Utilities jarsigner und keytool ersetzen das Utility des
JDK 1.1 javakey.
7
Security / Java-Sicherheit
Catrin Godau
Sicherheit in Applets
In HTML-Seiten eingebundene Applets werden vom Browser sofort aus dem Netz
geladen und gestartet. Internet-Explorer und Netscape-Navigator bieten die Möglichkeit
einzustellen, ob Applets im Browser ausgeführt werden dürfen oder nicht. Damit ist es
aber nicht möglich bestimmte Sicherheitsrestriktionen zu vergeben. Vor der Ausführung
des heruntergeladenen Bytecodes wird dieser zuerst durch den Bytecode-Verfier auf
Sicherheitsrestriktionen überprüft und nur dann zur Ausführung freigegeben, wenn der
Code korrekt ist. D.h., illegale Bytecodes werden gar nicht erst ausgeführt. Wenn der
Bytecode vom Verfier als korrekt eingestuft wird, und es sich um einen
sicherheitsrelevanten Befehl wie z.B. eine Dateioperation handelt, kommt der SecurityManager ins Spiel. Dieser überprüft zur Laufzeit alle sicherheitsrelevanten Operationen
daraufhin, ob sie ausgeführt werden dürfen oder nicht. Der Security-Manager wird
automatisch beim Start des Browsers bzw. Appletviewers gestartet und bleibt bis zur
Beendigung aktiv. Wird innerhalb eines Applets einschließlich JDK 1.1 eine illegale
Operation ausgeführt, löst das eine SecurityException aus. Ab JDK 1.2 wird eine
AccessControlException ausgelöst.
sicherheitsrelevante Operationen sind Dateizugriffe aller Art und Netzwerkoperationen.
Die Restriktionen, die vom Security-Manager überwacht werden, unterscheiden sich
zwischen Applets, die:

in einem Browser mit einer integrierten Virtual Machine gestartet werden

in einem Appletviewer oder über Java-Plug-In gestartet werden

übers Netz geladen werden

lokal geladen werden (auf der lokalen Platte und das Verzeichnis, in dem sich das
Applet befindet muß im CLASSPATH eingetragen sein).
In Verzeichnissen, die in der Umgebungsvariable CLASSPATH abgelegt sind, sollten nur
verifizierte Klassen stehen, da sie gegenüber anderen Klassen erweiterte
Zugriffsmöglichkeiten besitzen. Durch das name-space Konzept (Klassen werden beim
Laden je nach Herkunftsort in name-spaces abgelegt) ist es möglich Klassen mit gleichen
Namen zu laden. Befindet sich eine Klasse in einem name-space, der im CLASSPATH
eingetragen ist, hat sie erweiterte Rechte.
8
Internet Explorer, Netscape Communicator, Appletviewer, Java-Plug-In
Werden keine Einstellungen vorgenommen, gelten für diese Appletbetrachter folgende
Restriktionen:

Applets dürfen nicht auf lokale Dateien zugreifen

Applets dürfen nur zu dem Rechner Netzwerkverbindungen aufnehmen, von dem
sie geladen wurden.
Appletviewer, Java-Plug-In
Das vom JDK 1.2 eingeführte Sicherheitsmodell wird bisher nur vom Appletviewer und
Java-Plug-In implementiert, noch nicht von den Browsern!
Internet Explorer
Im Internet Explorer 4.0 können die Rechte relativ flexibel eingestellt werden:

lokale Applets (müssen sich im CLASSPATH befinden) haben prinzipiell die
gleichen Rechte wie Applikationen.

Die Seiten, die der Internet Explorer übers Netz lädt, werden, abhängig vom
Herkunftsort, in eine von vier Zonen eingeteilt. Jeder Zone können eigene JavaEinstellungen zugeordnet werden. Applets können so in unterschieldlichen Zonen
mit unterschhiedlichen Rechten ausgeführt werden.

Signierten Applets können wiederum andere Rechte zugeordnet werden als
nichtsignierten Applets, auch wenn sie nicht aus der selben Zone stammen.
Netscape Communicator
Das Sicherheitsmodell des Netscape Communicators weicht von den bisher beschrieben
ab. Soll ein Applet mit erweiterten Rechten ausgeführt werden, müssen in jedem Fall
Änderungen am Quellcode vorgenommen werden. Netscape hat für diesen Zweck die
Capabilities API entwickelt. Ein Applet, das eine sicherheitsrelevante Operation
durchführen will, muß diese Operation zunächst angefordert werden. Dies geschieht über
die Methode enablePrivilege() der Klasse
netscape.security.PrivilegeManager. Diese Klasse ist im JDK 1.2 nicht
9
Security / Java-Sicherheit
Catrin Godau
enthalten und muß gesondert von Netscape angefordert werden (download). Die
Anforderung eines solchen Rechts sieht könnte im Quellcode folgendermaßen aussehen:
PrivilegeManager.enablePrivilege(„UniversalPropertyRead“);
Als Parameter dienen die sogenannten System Targets. Beim Aufruf von
enablePrivilege() erscheint dem Benutzer ein Meldungsdialog, in dem er darüber
informiert wird, welche Operation das Applet durchführen will. Der Benutzer kann darufhin
die Aktion erlauebn oder verbieten. Wird die Operation erlaubt, hat das Applet solange
das angeforderte Recht, bis die Methode, in der der Aufruf stattfand beendet ist. Sollen
Applets in unterschiedlichen Browsern laufen, müssen auf Server-Seite verschiedene
Applet-Versionen bereitgestellt werden, mit enablePrivilege()-Aufrufen und ohne.
10
Beispiel für die Nutzung des SecurityManager
public class SecurityManagerDemo {
public static void main(String args[]) {
// Setzen des SecurityManagers
System.setSecurityManager(new IOSecurityManager());
// Verweis auf Datei anlegen
File f = new File("/tmp/test.dat");
try
{
// Versuch, in die Datei zu schreiben
FileOutputStream out = new FileOutputStream(f);
}
catch (IOException e)
{
e.printStackTrace();
}
}
}
class IOSecurityManager extends SecurityManager {
public void checkPropertyAccess(String key) {
// Abfrage von Dateipfad-Trennungszeichen erlauben
if ( ! key.equals("file.separator")
&& (! key.equals("path.separator")))
throw new SecurityException("Property not allowed");
}
public void checkRead(String file) {
// Nur Lesen von '/tmp/test.dat' erlaubt
11
Security / Java-Sicherheit
Catrin Godau
if (! file.equals("/tmp/test.dat"))
throw new SecurityException("you mustn't open this file");
}
public void checkDelete(String file) {
// Es darf keine Datei geläscht werden
throw
new SecurityException("you mustn't delete files");
}
public void checkWrite(String file) {
// Es darf in keine Datei geschrieben werden
throw
new SecurityException("you mustn't write files");
}
}
12
Mit dem JDK1.2 jar.exe ein neues Jar-File erstellen:
C:\jdk1.2\bin> jar
Usage: jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ...
Options:
-c create new archive
-t list table of contents for archive
-x extract named (or all) files from archive
-u update existing archive
-v generate verbose output on standard output
-f specify archive file name
-m include manifest information from specified manifest file
-0 store only; use no ZIP compression
-M Do not create a manifest file for the entries
-C change to the specified directory and include the following file
Aufruf im MS-DOS-Fenster, um aus den Dateien SystemInfo.class und LabelField.class
eine .jar-Datei zu erzeugen:
C:\jdk1.2\bin> jar cvf c:\catrin\security\test\sysinf.jar
c:\catrin\security\test\SystemInfo.class
c:\catrin\security\test\LabelField.class
added manifest
adding: c:/catrin/security/test/SystemInfo.class (in=3132)
(out=1561) (deflated 50%)
adding: c:/catrin/security/test/LabelField.class (in=1246)
(out=713) (deflated 42%)
Die Datei sysinf.jar wurde im Verzeichnis c:\catrin\security\test\ erzeugt!
13
Security / Java-Sicherheit
Catrin Godau
Mit dem JDK 1.2 keytool.exe eine neue .keystore - Datei erzeugen:
C:\jdk1.2\bin> keytool
keytool usage:
-certreq
[-v] [-alias <alias>] [-sigalg <sigalg>]
[-file <csr_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-delete
[-v] -alias <alias>
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-export
[-v] [-rfc] [-alias <alias>] [-file <cert_file>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-genkey
[-v] [-alias <alias>] [-keyalg <keyalg>]
[-keysize <keysize>] [-sigalg <sigalg>]
[-dname <dname>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>] [-storetype <storetype>]
-help
-identitydb [-v] [-file <idb_file>] [-keystore <keystore>]
[-storepass <storepass>] [-storetype <storetype>]
-import
[-v] [-noprompt] [-trustcacerts] [-alias <alias>]
[-file <cert_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-keyclone
[-v] [-alias <alias>] -dest <dest_alias>
[-keypass <keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-keypasswd [-v] [-alias <alias>]
14
[-keypass <old_keypass>] [-new <new_keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-list
[-v | -rfc] [-alias <alias>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
-printcert [-v] [-file <cert_file>]
-selfcert
[-v] [-alias <alias>] [-sigalg <sigalg>]
[-dname <dname>] [-validity <valDays>]
[-keypass <keypass>] [-keystore <keystore>]
[-storepass <storepass>] [-storetype <storetype>]
-storepasswd [-v] [-new <new_storepass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>]
Aufruf:
C:\jdk1.2\bin> keytool -genkey -alias catrin -keypass catrin keystore c:\catrin\security\test\.catrinskeystore -storepass
catrinspass
What is your first and last name?
[Unknown]:
catrin
What is the name of your organizational unit?
[Unknown]:
xxx
What is the name of your organization?
[Unknown]:
yyy
What is the name of your City or Locality?
[Unknown]:
bremen
What is the name of your State or Province?
[Unknown]:
germany
What is the two-letter country code for this unit?
[Unknown]:
de
Is <CN=catrin, OU=xxx, O=yyy, L=bremen, ST=germany, C=de> correct?
[no]:
yes
15
Security / Java-Sicherheit
Catrin Godau
Die Datei .catrinskeystore wurde im Verzeichnis c:\catrin\security\test\
erzeugt.
Durch den Aufruf:
C:\jdk1.2\bin>keytool -genkey -alias tom -keypass tomnoah keystore c:\catrin\security\test\.catrinskeystore -storepass
catrinspass
What is your first and last name?
[Unknown]:
tom
What is the name of your organizational unit?
[Unknown]:
kk
What is the name of your organization?
[Unknown]:
ll
What is the name of your City or Locality?
[Unknown]:
bremen
What is the name of your State or Province?
[Unknown]:
germany
What is the two-letter country code for this unit?
[Unknown]:
de
Is <CN=tom, OU=kk, O=ll, L=bremen, ST=germany, C=de> correct?
[no]:
yes
kann ein zusätzlicher Alias in der vorher angelegten Datei .catrinskeystore erzeugt
werden.
16
Mit dem JDK1.2 jarsigner.exe aus der mit jar.exe erzeugten jar-Datei eine
signierte jar-Datei erstellen:
C:\jdk1.2\bin>jarsigner
Usage: jarsigner [options] jar-file alias
jarsigner -verify [options] jar-file
[-keystore <url>]
keystore location
[-storepass <password>]
[-storetype <type>]
keystore type
[-keypass <password>]
[-sigfile <file>]
[-signedjar <file>]
[-verify]
[-verbose]
[-certs]
[-internalsf]
[-sectionsonly]
password for keystore integrity
password for private key (if different)
name of .SF/.DSA file
name of signed JAR file
verify a signed JAR file
verbose output when signing/verifying
display certificates when verbose and verifying
include the .SF file inside the signature block
don't compute hash of entire manifest
Aufruf:
C:\jdk1.2\bin> C:\jdk1.2\bin>jarsigner -keystore
c:\catrin\security\test\.catrinskeystore -storepass catrinspass signedjar c:\catrin\security\test\sysinfsignedcatrin.jar
c:\catrin\security\test\sysinf.jar catrin
Enter key password for catrin: catrin
C:\jdk1.2\bin>jarsigner -keystore
c:\catrin\security\test\.catrinskeystore -storepass catrinspass signedjar c:\catrin\security\test\sysinfsignedtom.jar
c:\catrin\security\test\sysinf.jar tom
Enter key password for tom: tomnoah
Die Dateien sysinfsignedcatrin.jar und sysinfsignedtom.jar wurden im
Verzeichnis c:\catrin\security\test\ erzeugt.
17
Security / Java-Sicherheit
Catrin Godau
18
Java – Sicherheits – Dateien /
Die Security – Datei (c:\catrin\security\test\java.security)  muß im Verzeichnis
{java.home}/lib/security/ oder {user.home}/ stehen.
security.provider.1=sun.security.provider.Sun
policy.provider=sun.security.provider.PolicyFile
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
policy.url.3=file:$c:\catrin\security\test\java.policy
policy.expandProperties=true
policy.allowSystemProperty=true
policy.ignoreIdentityScope=false
keystore.type=jks
system.scope=sun.security.provider.IdentityDatabase
package.access=sun.
19
Security / Java-Sicherheit
Catrin Godau
Policy - Datei
Benutzung des Policy Tools:
20
21
Security / Java-Sicherheit
Catrin Godau
22
Policy – Datei (c:\catrin\security\test\java.policy)
/* AUTOMATICALLY GENERATED ON Fri Jul 16 14:47:29 GMT+02:00 1999*/
/* DO NOT EDIT */
keystore "c:\catrin\security\test\.catrinskeystore";
grant codeBase "file:${java.home}/lib/ext/-" {
permission java.security.AllPermission;
};
grant {
permission java.lang.RuntimePermission "stopThread";
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.util.PropertyPermission "java.version", "read";
permission java.util.PropertyPermission "java.vendor", "read";
permission java.util.PropertyPermission "java.vendor.url", "read";
permission java.util.PropertyPermission "java.class.version", "read";
permission java.util.PropertyPermission "os.name", "read";
permission java.util.PropertyPermission "os.version", "read";
permission java.util.PropertyPermission "os.arch", "read";
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
permission java.util.PropertyPermission "java.specification.version", "read";
permission java.util.PropertyPermission "java.specification.vendor", "read";
permission java.util.PropertyPermission "java.specification.name", "read";
permission java.util.PropertyPermission "java.vm.specification.version", "read";
permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
permission java.util.PropertyPermission "java.vm.specification.name", "read";
permission java.util.PropertyPermission "java.vm.version", "read";
permission java.util.PropertyPermission "java.vm.vendor", "read";
permission java.util.PropertyPermission "java.vm.name", "read";
};
grant signedBy "catrin", codeBase "file://c:\catrin\security\test\sysinfsignedcatrin.jar" {
permission java.util.PropertyPermission "user.name", "read, write", signedBy "catrin";
permission java.util.PropertyPermission "user.home", "read, write", signedBy "catrin";
permission java.util.PropertyPermission "user.dir", "read, write", signedBy "catrin";
};
grant signedBy "tom", codeBase "file://c:\catrin\security\test\sysinfsignedtom.jar" {
permission java.util.PropertyPermission "java.version", "read, write", signedBy "tom";
permission java.util.PropertyPermission "java.vendor", "read, write", signedBy "tom";
};
23
Security / Java-Sicherheit
Catrin Godau
Listing des Beispiel-Applets
Datei SystemInfo.java
________________________________________________________________
import java.applet.*;
import java.awt.*;
class LabelField extends Panel {
int labelWidth;
Label lbl;
TextField field;
public LabelField(int labelWidth, String lbl, String val) {
this.labelWidth = labelWidth;
add(this.lbl = new Label(lbl));
add(this.field = new TextField(val));
field.setEditable(false);
}
public void layout() {
Dimension d = size();
Dimension p1 = lbl.preferredSize();
Dimension p2 = field.preferredSize();
lbl.reshape(0, 0, labelWidth, p1.height);
field.reshape(labelWidth + 5, 0, d.width - (labelWidth + 5),
p2.height);
}
}
public class SystemInfo extends Applet {
24
CardLayout c;
Panel p;
public void init() {
Font lbl = new Font("Helvetica", Font.BOLD, 14);
setLayout(new BorderLayout());
add("South", p = new Panel());
p.add(new Button("Next"));
p.add(new Button("Previous"));
add("Center", p = new Panel());
p.setLayout(c = new CardLayout());
Panel p2 = new Panel();
p2.setLayout(new GridLayout(0, 1));
p2.add(new Label("System Properties")).setFont(lbl);
p2.add(new LabelField(100, "version:",
System.getProperty("java.version")));
p2.add(new LabelField(100, "vendor:",
System.getProperty("java.vendor")));
p2.add(new LabelField(100, "vendor.url:",
System.getProperty("java.vendor.url")));
p.add("system", p2);
p2 = new Panel();
p2.setLayout(new GridLayout(0, 1));
p2.add(new Label("User Properties")).setFont(lbl);
p2.add(new LabelField(100, "User:",
System.getProperty("user.name")));
p2.add(new LabelField(100, "Home:",
System.getProperty("user.home")));
p2.add(new LabelField(100, "Current:",
System.getProperty("user.dir")));
p.add("user", p2);
25
Security / Java-Sicherheit
Catrin Godau
p2 = new Panel();
p2.add(new Label("Java Properties")).setFont(lbl);
p2.setLayout(new GridLayout(0, 1));
p2.add(new LabelField(100, "java home:",
System.getProperty("java.home")));
p2.add(new LabelField(100, "class version:",
System.getProperty("java.class.version")));
p2.add(new LabelField(100, "class path:",
System.getProperty("java.class.path")));
p.add("java", p2);
p2 = new Panel();
p2.setLayout(new GridLayout(0, 1));
p2.add(new Label("OS Properties")).setFont(lbl);
p2.add(new LabelField(100, "OS:",
System.getProperty("os.name")));
p2.add(new LabelField(100, "OS Arch:",
System.getProperty("os.arch")));
p2.add(new LabelField(100, "OS Version:",
System.getProperty("os.version")));
p.add("os", p2);
p2 = new Panel();
p2.setLayout(new GridLayout(0, 1));
p2.add(new Label("Misc Properties")).setFont(lbl);
p2.add(new LabelField(100, "File Separator:",
System.getProperty("file.separator")));
p2.add(new LabelField(100, "Path Separator:",
System.getProperty("path.separator")));
p2.add(new LabelField(100, "Line Separator:",
System.getProperty("line.separator")));
p.add("sep", p2);
}
public boolean action(Event evt, Object obj) {
if ("Next".equals(obj)) {
26
c.next(p);
return true;
}
if ("Previous".equals(obj)) {
c.previous(p);
return true;
}
return false;
}
}
____________________________________________________________
27
Security / Java-Sicherheit
Catrin Godau
Einbinden der signierten und unsignierten Applet-Klassen in eine HTML Seite,
die auf irgendeiner WebPage verfügbar ist:
____________________________________________________________________
<HTML>
<HEAD>
<TITLE>SystemInfo-HTML unsigned</TITLE>
</HEAD>
<BODY>
<APPLET CODE="sysinf.jar" WIDTH=430 HEIGHT=270></APPLET>
</BODY>
</HTML>
_____________________________________________________________________
<HTML>
<HEAD>
<TITLE>SystemInfo-HTML signed Catrin</TITLE>
</HEAD>
<BODY>
<APPLET CODE="sysinfsignedcatrin.jar" WIDTH=430 HEIGHT=270></APPLET>
</BODY>
</HTML>
______________________________________________________________________
<HTML>
<HEAD>
<TITLE>SystemInfo-HTML signed Tom</TITLE>
</HEAD>
<BODY>
<APPLET CODE="sysinfsignedtom.jar" WIDTH=430 HEIGHT=270></APPLET>
</BODY>
</HTML>
______________________________________________________________________
28
nun kann durch den Besuch der WebPage das Applet ausgeführt werden und die
verschiedenen Restriktionen bzw. Schreib- und Leserechte können getestet werden.
Quellen
C:\jdk1.2\docs\guide\security\permissions.html
C:\jdk1.2\docs\guide\security\PolicyFiles.html
C:\jdk1.2\docs\tooldocs\win32\keytool.html
C:\jdk1.2\docs\guide\security\spec\security-spec.doc.html
Unix open Mai 99 „Raus aus dem Sandkasten“ (Manfred Simon)
O’Reilly JAVA in an Nutshell 1998
29