5.4 Code Access Security
Ein wichtiges Merkmal des .NET Frameworks (aber nicht des .NET Compact Frameworks) ist die Code Access Security.
Normalerweise kann eine Applikation auf alle Ressourcen zugreifen, auf die der Benutzer, der die Applikation startet, Zugriff hat. Der Schwachpunkt liegt auf der Hand: Häufig starten Benutzer recht unbedacht eine Applikation, die beispielsweise per E-Mail auf die Maschine gekommen ist, haben aber überhaupt keine Kontrolle darüber, was diese Applikation nun überhaupt tut: Vielleicht installiert sie eine Backdoor, durchsucht das Filesystem, greift auf das Internet zu oder klaut E-Mail-Adressen. Mit anderen Worten: Einer Applikation, die gestartet ist, sind nur noch Riegel in Form der Benutzerberechtigungen vorgeschoben. Das bedeutet, dass die gestartete Applikation, je nach Benutzerumgebung, relativ frei »schalten und walten« kann.
Das Prinzip der Code-Access-Security-Richtlinien (CASpol) bringt hier sehr deutliche Verbesserungen – allerdings nur für Managed Applications!
Für jede einzelne Assembly (das kann eine .exe- oder .dll-Datei sein) kann individuell definiert werden, auf welche Ressourcen diese zugreifen kann.
Abbildung 5.8 Erstellen eines Berechtigungssatzes mit dem Konfigurationswerkzeug des .NET Frameworks
Abbildung 5.8 zeigt die Konfiguration eines Berechtigungssatzes: Eine Assembly darf den SQL-Client verwenden und im Verzeichnis c:\temp lesend und schreibend auf Dateien zugreifen. Sonst nichts! Kein Zugriff auf andere Netzwerkressourcen, keine Manipulation der Registrierung etc.
Im Klartext bedeutet das, dass Sie festlegen, was eine ausführbare Datei darf, und dass sich die ausführbare Datei eben nicht das holen kann, was sie gern hätte. Obwohl diese Vorgehensweise eindeutig in die richtige Richtung weist, muss man die Euphorie zunächst bremsen: Die Code Access Security funktioniert ausschließlich mit Managed Code, der von der Laufzeitumgebung des .NET Frameworks ausgeführt wird. Solange Sie nicht Unmanaged Code auf den Systemen komplett ausschließen können, gibt es durch das Verfahren natürlich keine verbesserte Gesamtsicherheit. Um bösartigen Unmanaged Code auszuschließen, können Sie beispielsweise auf die »Richtlinien für Softwareeinschränkungen« (Gruppenrichtlinien) zurückgreifen.
Code Access Security kann natürlich nur funktionieren, wenn Sie das Konzept nicht aushebeln und alle Assemblys mit »Full Trust«, also ohne Einschränkungen, laufen lassen.
Damit Sie einen »visuellen Eindruck« bekommen, wie es aussieht, wenn die Code Access Security den Ressourcenzugriff verhindert, habe ich ein kleines Programm geschrieben, das versucht, auf einen SQL-Server zuzugreifen. Da die Assembly (d. h. die .exe-Datei) keine Berechtigung dazu hat, wird der Zugriff verhindert (Abbildung 5.9).
Abbildung 5.9 Ein Programm versucht, auf den SQL-Server zuzugreifen. Die Code Access Security verhindert den Zugriff.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.
