Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort

Download:
- ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel (8. Auflage)

Java ist auch eine Insel (8. Aufl.)
8., aktual. Auflage, geb., mit DVD
1.475 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1371-4
Pfeil 26 Sicherheitskonzepte
Pfeil 26.1 Zentrale Elemente der Java-Sicherheit
Pfeil 26.1.1 Security-API der Java SE
Pfeil 26.1.2 Cryptographic Service Providers
Pfeil 26.2 Der Sandkasten (Sandbox)
Pfeil 26.3 Sicherheitsmanager (Security Manager)
Pfeil 26.3.1 Der Sicherheitsmanager bei Applets
Pfeil 26.3.2 Sicherheitsmanager aktivieren
Pfeil 26.3.3 Rechte durch Policy-Dateien vergeben
Pfeil 26.3.4 Erstellen von Rechtedateien mit dem grafischen Policy-Tool
Pfeil 26.3.5 Kritik an den Policies
Pfeil 26.4 Signierung
Pfeil 26.4.1 Warum signieren?
Pfeil 26.4.2 Digitale Ausweise und die Zertifizierungsstelle
Pfeil 26.4.3 Mit keytool Schlüssel erzeugen
Pfeil 26.4.4 Signieren mit jarsigner
Pfeil 26.5 Digitale Unterschriften
Pfeil 26.5.1 Die MDx-Reihe
Pfeil 26.5.2 Secure Hash Algorithm (SHA)
Pfeil 26.5.3 Mit der Security-API einen Fingerabdruck berechnen
Pfeil 26.5.4 Die Klasse MessageDigest
Pfeil 26.6 Verschlüsseln von Daten(-strömen)
Pfeil 26.6.1 Den Schlüssel bitte
Pfeil 26.6.2 Verschlüsseln mit Cipher
Pfeil 26.6.3 Verschlüsseln von Datenströmen
Pfeil 26.7 Zum Weiterlesen


Galileo Computing - Zum Seitenanfang

26.3 Sicherheitsmanager (Security Manager) Zur nächsten ÜberschriftZur vorigen Überschrift

Über Applets wissen wir bereits, dass sie auf einige Ressourcen des Rechners nicht zugreifen dürfen. Zwischen dem Aufrufer einer Bibliotheksfunktion und dem Betriebssystem sitzt eine Einheit, die unsere Aktionen genau kontrolliert. Dieses Zwischensystem ist der Sicherheitsmanager. Standardmäßig startet die Laufzeitumgebung für Applikationen ohne Sicherheitsmanager, für Applets gibt es jedoch spezielle Sicherheitsmanager. Jeder Sicherheitsmanager ist eine Unterklasse von SecurityManager. Den aktuellen Sicherheitsmanager liefert die Funktion getSecurityManager() aus der Klasse java.lang.System. Führen wir folgende Zeile in einer Applikation aus, so sehen wir, dass anfänglich kein Sicherheitsmanager gesetzt ist, da die Ausgabe null ist.

public class ApplicationSecManager 
{ 
  static public void main( String[] args ) 
  { 
    System.out.println( System.getSecurityManager() ); 
  } 
}

Im Gegensatz dazu sind wir bei Applets mit einem etwas anderen Bild konfrontiert. Das folgende Programm liefert eine Ausgabe wie sun.applet.AppletSecurity@123456 auf dem Bildschirm. Die Zahl ist der Hashcode des Objekts:

public class Applet1 extends java.applet.Applet 
{ 
  public void paint( java.awt.Graphics g ) 
  { 
    g.drawString( System.getSecurityManager().toString(), 10, 10 ); 
  } 
}

Galileo Computing - Zum Seitenanfang

26.3.1 Der Sicherheitsmanager bei Applets Zur nächsten ÜberschriftZur vorigen Überschrift

Die beiden Beispiele machen deutlich, dass dem Applet ein Security-Manager zugewiesen ist und den Applikationen kein Sicherheitsmanager etwas verbietet. Doch was ist einem Applet eigentlich verboten?

  • Applets dürfen nicht auf lokale Dateien des Client-Rechners zugreifen, sie etwa erzeugen, lesen, modifizieren oder löschen. Sonst könnten sie wichtige Systemdateien an ihren Heimatserver übermitteln, und das stellt ein ernsthaftes Risiko dar.
  • Applets können außerdem keine Netzwerkverbindungen zu anderen Computern als dem Heimatserver aufnehmen; dies gilt für alle Verbindungen, die mit den Netzwerk-Klassen URL, Socket und DatagramSocket möglich sind – was oft einen Einschnitt darstellt, weil etwa ein Börsenticker-Applet Kursdaten von einem anderen Server holen möchte. Das Internet als verteiltes System sollte auch vollständig genutzt werden können. Da Applets nicht in der Lage sind, Verbindungen zu Fremdrechnern aufzubauen, können sie natürlich auch nicht als Server fungieren.
  • Weiterhin kann ein Applet keine Programme ausführen, die auf dem lokalen Rechner liegen. Applets dürfen auch keine anderen Programme starten und keine nativen Bibliotheken laden. (Für normale System-DLLs bringt das ohnehin nichts, da sie nicht über die benötigte Namenskonvention verfügen.)
  • Threads sind ein etwas anderes Problem. Da alle Applets gemeinsam in einer JVM laufen, muss gewährleistet sein, dass sich nur die Threads eines Applets (also die Threads in der Thread-Gruppe des Applets) beeinflussen dürfen. In der Vergangenheit traten mehrfach Sicherheitsprobleme auf, bei denen sich Threads verschiedener Applets in die Quere kamen. Auch darf kein Applet die gemeinsam genutzte virtuelle Maschine beenden.
  • Applets dürfen keinen eigenen Sicherheitsmanager installieren. Könnte das ein Applet, ließen sich leicht die für Applets geltenden Beschränkungen aushebeln. Der Java-fähige Webbrowser erzeugt für uns ein spezielles ClassLoader-Objekt, das abgesichert arbeitet.
  • Die Java-Umgebung setzt automatisch einige Properties, damit unser Programm etwas über seine Umgebung erfahren kann. Diese Variablen lassen sich über System.getProperty(String) auslesen. Applets dürfen nur manche Variablen lesen. Sie haben keinen Zugriff auf Informationen über das Java-Home-Directory, den Java-Klassenpfad, den User-Namen, das Home-Verzeichnis und das Arbeitsverzeichnis des Anwenders. Die anderen Daten in den Variablen sind frei. Dazu gehören etwa: java.version, java.vendor, java.vendor.url, java.class.version, os.name, os.arch, os.version, file.separator, path.separator, line.separator. Obwohl diese Daten natürlich für statistische Zwecke missbraucht werden können, sind sie doch für ein Applet unter Umständen lebensnotwendig: So kann es etwa einfach an der Versionsnummer ablesen, ob eine bestimmte Klasse mit Methoden bestimmter Versionen implementiert ist oder nicht (andernfalls muss die Implementierung dies über eine Exception testen).

Galileo Computing - Zum Seitenanfang

26.3.2 Sicherheitsmanager aktivieren Zur nächsten ÜberschriftZur vorigen Überschrift

Nehmen wir ein Programm SecTest an, welches den aktuellen Sicherheitsmanager anzeigt und dann die Länge einer Datei ausgibt.

Listing 26.1 com/tutego/security/SecTest.java

package com.tutego.security; 
 
import java.io.File; 
 
public class SecTest 
{ 
  public static void main( String[] args ) 
  { 
    System.err.println( System.getSecurityManager() ); 
 
    System.err.println( new File( "c:/address.txt" ).length() ); 
  } 
}

Die Schalter -Djava.security.debug und -Djava.security.manager

Wenn wir das Programm starten, läuft es durch und gibt die Länge der Datei aus. Mit dem Schalter -Djava.security.debug=all können Sicherheitsprüfungen geloggt werden, und wir bekommen Ausgaben wie

$ java -Djava.security.debug=all com.tutego.security.SecTest 
scl:  getPermissions ProtectionDomain  (file:/S:/25_Sicherheitskonzepte/ <no signer certificates>) 
 sun.misc.Launcher$AppClassLoader@11b86e7 
 <no principals> 
 java.security.Permissions@1a46e30 ( 
 (java.io.FilePermission \S:\25_Sicherheitskonzepte\- read) 
 (java.lang.RuntimePermission exitVM) 
) 
scl: 
null 
42924

Geben wir beim Start den Schalter -Djava.security.manager an, so meldet die Laufzeitumgebung einen Standard-Sicherheitsmanager an. Ein println(System.getSecurityManager()) liefert dann eine Ausgabe wie »java.lang.SecurityManager@26b249« (auch mit -Djava.security.manager=MeineSecManagerKlasse lässt sich arbeiten).

Soll eine potenziell kritische Operation wie das Erfragen der Dateilänge ausgeführt werden, steigt die Laufzeitumgebung mit einer Exception aus, weil der Sicherheitsmanager das standardmäßig nicht zulässt:

$ java -Djava.security.manager com.tutego.security.SecTest 
java.lang.SecurityManager@26b249 
Exception in thread "main" java.security.AccessControlException: access denied Zeilen-Umbruch 
  (java.io.FilePermission c:\address.txt read) 
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) 
 at java.security.AccessController.checkPermission(AccessController.java:401) 
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) 
at java.lang.SecurityManager.checkRead(SecurityManager.java:887) 
at java.io.File.length(File.java:790) 
at SecTest.main(SecTest.java:9) 
Wie nutzen die Java-Bibliotheken den Sicherheitsmanager?

Ein Sicherheitsmanager hat die Kontrolle über alle problematischen (also potenziell gefährlichen) Methoden in der Java-Bibliothek. Alle Methoden, die irgendetwas mit Sicherheit zu schaffen haben, fragen vorher den Sicherheitsmanager, ob sie überhaupt zu der kritischen Aktion berechtigt sind. Sehen wir uns dazu die Methode list() aus der Klasse java.io.File an:

public String[] list() 
{ 
  SecurityManager security = System.getSecurityManager(); 
  if ( security != null ) 
    security.checkRead( path ); 
  return fs.list( this ); 
}

Wir erkennen, dass die Methode zunächst den Sicherheitsmanager konsultiert und dann erst die wahre Aktion ausführt. Betrachten wir das Beispiel, so ist dies typisch für alle anderen Methoden aus der File-Klasse und macht deutlich, dass es keine Möglichkeit gibt, um diesen Sicherheitsmanager herumzukommen; es sei denn, die Methode list() vom internen FileSystem-Objekt ließe sich direkt aufrufen – was aber nicht möglich ist, weil fs fest als privates statisches Attribut in der Klasse File verankert ist. Sogar Unterklassen können fs also weder sehen noch nutzen.

So wie die File-Klasse mit dem SecurityManager arbeitet, rufen auch andere Klassen Prüf-methoden auf, um zu entscheiden, ob der Zugriff auf eine Ressource erlaubt ist. Verweigert der Sicherheitsmanager eine Operation, löst er eine SecurityException aus. Der Sicherheitsmanager kann zum Beispiel beschränken:

  • Toolkit. Können wir mit getSystemEventQueue() die Systemschlange für Ereignisse abfragen?
  • Window. Erzeugt in einem Applet zusätzlich die Einblendung »Warning: Applet Window«.
  • FileInputStream. Dürfen wir ein solches Objekt überhaupt erzeugen?
  • Class. Dürfen wir auf Elemente der Klasse zugreifen?
  • ClassLoader. Können wir einen neuen Klassenlader definieren?
  • Runtime. Können wir mit exit() aussteigen oder externe Programme ausführen?

Galileo Computing - Zum Seitenanfang

26.3.3 Rechte durch Policy-Dateien vergeben Zur nächsten ÜberschriftZur vorigen Überschrift

Zwar könnte ein Programm einen eigenen Sicherheitsmanager vom Typ SecurityManager installieren, doch das ist in Java in der Regel nicht nötig. Es gibt bessere Möglichkeiten, Sicherheitseinstellungen vorzunehmen. Um einem Programm die passenden Rechte zu geben – und damit in unserem Fall Zugriff auf die Dateilänge zu bekommen –, werden die zugesicherten Rechte in einer Policy-Datei gesammelt. Bekommt die Laufzeitumgebung beim Start einen Verweis auf die Policy-Datei, wird der Security-Manager auf die vergebenen Berechtigungen Rücksicht nehmen. Bei der Vergabe von Rechten können zusätzlich angegeben werden:

  • Codebase. Vergibt Rechte für Klassen, die von einem bestimmten Ort kommen.
  • Signierung. Es wird nur das Recht eingeräumt, wenn Programmcode signiert ist.
  • Principal. Gewährt bestimmte Rechte für authentifizierte Benutzer.

Policy-Dateien mit grant-Anweisungen

Die Policy-Dateien bestehen aus einer Reihe von grant-Anweisungen. Sehen wir uns die Datei myPol.policy an, die für alle Dateien eine Leseberechtigung vergibt:

Listing 26.2 myPol.policy

grant { 
 permission java.io.FilePermission   "<<ALL FILES>>",  "read"; 
};

java.security.manager

Nun muss diese Berechtigungsdatei mit dem Sicherheitsmanager verbunden werden. Das geschieht am komfortabelsten von der Kommandozeile aus:

$ java -Djava.security.manager Djava.security.policy=myPol.policy 
 com.tutego.security.SecTest 
java.lang.SecurityManager@26b249 
28

Wir sehen, dass das Programm nun durchläuft und die Dateilänge ausgibt. Der Schalter -Djava.security.policy gibt einen Pfad auf die Berechtigungsdatei an. Die Datei muss im Pfad gefunden oder absolut adressiert werden.

Standard-Policy-Dateien

Neben diesen benutzerdefinierten Rechteregeln gibt es vom System vergebene Policy-Dateien. Sie werden von Java standardmäßig in der Datei java.policy im Unterverzeichnis lib/security (etwa C:\Programme\Java\jre1.6.0\lib\security, aber auch jdk) der Java-Installation gespeichert. Diese Rechtedatei definiert damit die »Standardberechtigungen«.

Listing 26.3 jre1.6.0\lib\security\java.policy, Ausschnitt

// Standard extensions get all permissions by default 
grant codeBase "file:${java.home}/lib/ext/*" { 
  permission java.security.AllPermission; 
};

Alle Bibliotheken, die in das ext-Verzeichnis gelegt werden, bekommen alle Rechte. Das liegt an den Systemrechten. Das zeigt auch die Verwendung einer Code-Base: Sie spezifiziert den genauen Pfad, in dem die Rechte gelten. Also werden nur für das lib/ext-Verzeichnis alle Rechte vergeben, aber nicht für alle anderen.

Eigene, systemunabhängige Rechtedateien können wir unter dem Namen java.policy im Benutzerverzeichnis ablegen. Auch diese Dateien kann der Systemverwalter anpassen. Zunächst werden die Standardsicherheitsdateien genutzt und die Benutzerdateien »nachgeladen«. Eine weitere Datei java.security im Verzeichnis security der JRE und des JDK beschreibt, welche Rechtedateien genutzt werden. Genau dort befinden sich die beiden Dateien.

Listing 26.4 jre1.6.0\lib\security\java.security, Ausschnitt

# The default is to have a single system-wide policy file, 
# and a policy file in the user’s home directory. 
policy.url.1=file:${java.home}/lib/security/java.policy 
policy.url.2=file:${user.home}/.java.policy

Die Datei ist ebenso wichtig, wenn neue Provider, also Implementierungen der Kryptografie-API, angemeldet werden.

Da Rechte nur vergeben, aber bisher nicht genommen werden können, besteht das Sicherheitsproblem darin, dass eine eigene Policy-Datei alle Rechte vergibt, wogegen die Systemdatei Einschränkungen vorsieht. In diesem Fall kann der Programmverwalter auch dem Benutzer das Recht nehmen, eigene Rechtedateien anlegen zu können. Dazu editiert er die Datei java.security. Der Eintrag allowSystemProperty muss false sein.

# whether or not we allow an extra policy to be passed on the command line 
# with -Djava.security.policy=somefile. Comment out this line to disable 
# this feature. 
policy.allowSystemProperty=true

Galileo Computing - Zum Seitenanfang

26.3.4 Erstellen von Rechtedateien mit dem grafischen Policy-Tool Zur nächsten ÜberschriftZur vorigen Überschrift

Das grafische Dienstprogramm policytool gibt uns die Möglichkeit, Applikationen und signierten Applets spezielle Rechte einzuräumen oder zu verweigern. Das Policy-Tool nimmt uns die Arbeit ab, von Hand die Rechtedateien zu editieren.

Nach dem Aufruf des Programms policytool öffnet sich ein Fenster, das uns einige Menüpunkte bereitstellt, über die wir bestehende Rechtedateien editieren oder auch neue anlegen können.

Abbildung 26.1 Das grafische Policy-Tool

Neue Einträge für die Zugeständnisse der Laufzeitumgebung an das Programm werden über das Menü Add Policy Entry vorgenommen. Über das Dialogfenster können anschließend eine Reihe von erlaubten Eigenschaften sowie Permissions ausgewählt werden. Die folgende Tabelle zeigt einige Permissions und ihre Bedeutungen:


Permission Bedeutung

AllPermission

Die Anwendung oder das Applet darf alles

FilePermission

Zugriff auf Dateien und Verzeichnisse

NetPermission

Zugriff auf Netzwerkressourcen

PropertyPermission

Zugriff auf Systemeigenschaften

ReflectPermission

Zugriff über Reflection auf andere Objekte erlauben

RuntimePermission

Einschränkungen von Laufzeitsystemen wie Klassenlader

SecurityPermission

Einstellen eines allgemeinen Sicherheitskonzepts, etwa für den Zugriff auf Policies

SerializablePermission

Beschränkung der Serialisierung

SocketPermission

Spezielle Einschränkungen an einer Socket-Verbindung



Galileo Computing - Zum Seitenanfang

26.3.5 Kritik an den Policies topZur vorigen Überschrift

Die Policies sind eine nette Sache, um für eine Applikation die Rechte einzuschränken oder zu vergeben, doch sie sind nicht unproblematisch.

Format der Policy-Dateien

Policy-Dateien sind standardmäßig Textdateien auf der Clientseite des Anwenders. Ein Anwender kann diese Textdateien ohne große Probleme ändern und mehr Rechte zugestehen. Die Rechtedateien sind durch keine Prüfsumme gesichert, um Änderungen gegebenenfalls zu erkennen. Zum anderen ist das Textformat nicht mehr so »modern«, und XML-basierte Textformate lösen proprietäre Dateiformate immer mehr ab.

Da sich das Sicherheitssystem von Java jedoch beliebig erweitern lässt, lassen sich die Standardtextformate durch ein neues System ersetzen, das etwa XML-Dateien liest und eine (mit einer digitalen Signatur gesicherte) Prüfsumme speichert, die nicht mehr so leicht veränderbar ist.

Kein Refresh

Wurden Policy-Dateien einmal vom System eingelesen, können sie zwar nachträglich verändert werden, doch das Java-System erkennt diese Änderung nicht. Als Konsequenz muss die Applikation neu gestartet werden. Das ist für Benutzerapplikationen kein großes Dilemma, doch für serverseitige Applikationen ein großes Problem. Es ist unmöglich, für eine kleine Änderung an den Policy-Dateien etwa den EJB-Server herunterzufahren und wieder neu zu starten. Angenommen, das System ist ein Five-Nine-System, weist also eine Verfügbarkeit von 99,999 % auf, so würde dies eine erlaubte Ausfallzeit von etwa fünf Minuten ausmachen – was bei laufender Änderung der Policies kaum zu erreichen ist.

Keine Rollen bei der Rechtevergabe

Der Zweck des Policy-Verfahrens besteht darin, einem Programm Rechte zuzuordnen. Die Rechte können weiterhin für Programme vergeben werden, die von einem bestimmten Ort kommen (CodeSource) und von einem bestimmten Anwender signiert sind (SignedBy). Was wäre, wenn wir einem bestimmten Benutzer Rechte zuordnen wollten? Das ist nicht so einfach möglich. Jeder Benutzer müsste dann das Jar-Archiv signieren, und der Policy-Datei wäre zu entnehmen, was jedem Benutzer zustünde. Doch das taugt nichts! Käme ein Benutzer hinzu, müsste das Archiv neu signiert werden – bei 10.000 Benutzern ein undenkbares Unterfangen. Des Weiteren könnte der Benutzer selbst seine Rechte erweitern, was nicht sinnvoll wäre.

Wir brauchen also nicht nur ein Verfahren, das nach den Quellen, sondern auch nach Rollen unterscheidet. Dieses Verfahren heißt rollenbasierte Rechtevergabe. Jedem Benutzer ist eine Rolle zugeordnet, und anhand dieser Rolle werden ihm Rechte zugewiesen. Das Betriebssystem Windows nutzt zum Beispiel diesen Typ der Rechtevergabe.

JAAS (Java Authentication and Authorization Service)

Sun hat die Notwendigkeit eines rollenbasierten Systems erkannt und JAAS (Java Authentication and Authorization Service) entworfen. JAAS ist Bestandteil seit Java 1.4. Die beiden Hauptteile sind:

  • Authentifikation/Authentifizierung. Gibt die Identität einer Person oder eines Programms gegenüber einem Kommunikationspartner an.
  • Autorisierung. Sicherstellen der Rechte, sodass ein Benutzer Aktionen durchführen kann beziehungsweise ihm Aktionen verwehrt bleiben.

Das JAAS ist damit eine Java-Version eines Pluggable Authentication Module (PAM).

Wichtig in diesem Zusammenhang sind Login-Module. Sie erlauben die Anmeldung an eine Instanz, sodass sich der Benutzer authentifizieren kann. Dies kann ein komplexes System wie Kerberos sein, aber auch eine Smart-Card oder ein biometrisches System. Einige Login-Module liefert Sun mit jeder Laufzeitumgebung mit aus. Hat sich der Benutzer (das Subject) mit dem Login-Modul authentifiziert, verbindet JAAS ihn mit authentifizierten Benutzerkennungen, die Principal heißen.

Bei den Policy-Dateien haben wir nun gesehen, wie die Rechte auch für eine Codebase, einen Signierer und auch einen Principal vergeben werden können. Der Sicherheitsmanager ermöglicht also einem Programmstück nur dann die Ausführung, wenn ein Benutzer angemeldet ist und die nötigen Rechte hat. Der Programmcode muss also keine Implementierung mit Fallunterscheidungen für diverse Rollen aufweisen, sondern kann einfach in der Policy-Datei mit einem Principal assoziiert werden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2009
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de