Zugang verboten Sicherheitszonen im .NET Framework

Werden Rechner in ein Intranet eingebunden oder online mit dem Internet verbunden, unterliegen sie besonderen Sicherheitsrisiken und sind Angriffen, Virenattacken, Spam und Trojanern ausgeliefert. Regelmäßige Security-Updates, verbesserte Firewalls, neue Anti-Spam-Tools und erweiterte Virenprogramme sowie -signaturen sollen die Risiken dauerhaft minimieren. Im .NET Framework hilft ein ausgeklügeltes Sicherheitssystem, Berechtigungen bereits im Rahmen der Programmentwicklung zu berücksichtigen.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Fsas Technologies GmbH

SEPPmail - Deutschland GmbH

Microsoft Deutschland GmbH

Das .NET Framework stellt ein gesondertes Sicherheitssystem für die Common Language Runtime (CLR) bereit. Jede .NET-Anwendung agiert ihrerseits mit diesem Sicherheitssystem. Um die Codezugriff-Sicherheit (CAS - Code Access Security) zu gewährleisten, wird jeder Anwendung bei deren Ausführung ein bestimmter Berechtigungssatz (Permission Set) zugewiesen.

Darüber wird bestimmt, ob und welche Funktionalitäten einer Anwendung ausgeführt werden dürfen. Ist aufgrund des zugewiesenen Berechtigungssatzes die Ausführung einer Programmfunktion nicht möglich, löst diese Programmfunktion eine Sicherheitsausnahme (Security Exception) auf einem Rechner aus, die programmintern ausgewertet werden kann.

Der Berechtigungssatz und die Berechtigungen für eine Anwendung sind abhängig von der Konfiguration des .NET-Sicherheitssystems. Dementsprechend können auch die Ausführung eines Programms und die Zulässigkeit von Programmfunktionen je nach Computerkonfiguration variieren.

Die Sicherheit von .NET erweitert die Security-Funktionen des jeweils verwendeten Betriebssystems. Anwendungen, die unter .NET ausgeführt werden, werden einer der folgenden Sicherheitszonen zugewiesen:

• My Computer/Arbeitsplatz: Die Anwendung wird lokal auf dem Rechner ausgeführt.
• Local Intranet/Lokales Intranet: Die Anwendung wird über eine freigegebene Intranet-Ressource ausgeführt.
• Internet: Die Anwendung wird direct über das Internet ausgeführt.
• Trusted Sites/Vertrauenswürdige Sites: Die Anwendung wird über eine Internetseite ausgeführt, der über den Internet Explorer Vertrauenswürdigkeit bescheinigt wurde.
• Untrusted Sites/Nicht vertrauenswürdige Sites: Die Anwendung wird über eine Internetseite ausgeführt, der über den Internet Explorer keine Vertrauenswürdigkeit bescheinigt wurde.

Sicherer Code durch Identifizierung

Bevor einem Assembly Berechtigungen zugewiesen werden, wird das jeweilige Assembly beim Laden selbst analysiert und auf dessen Beweiskraft (Evidence) hin untersucht. Grundlage der Analyse ist dabei der mitunter vergebene Strong Name (starker Name) des Assemblies, der zugewiesene Authentifizierungscode des jeweiligen Software-Herstellers oder aber der URL-Ursprung.

Entwickeln Sie selbst Komponenten müssen Sie sicherstellen, dass diese von unterschiedlichen Installationsorten aus ausführbar sind, dass deren Funktionen korrekt arbeiten, dass die Funktionen nicht missbraucht werden können und dass der Komponente selbst durch eine Signierung vertraut werden kann. Ferner muss sichergestellt werden, dass die Komponente nicht selbst unzulässigerweise geändert wird. Dies wird im .NET Framework dadurch erreicht, indem jedem Assembly ein Hash-Wert zugeordnet wird, der aus der Quersumme sämtlicher Bytes generiert wird und im Manifest abgelegt wird.

Dieser Hash-Wert wird beim Laden des Assemblies neu gebildet und mit dem im Manifest gespeicherten Wert verglichen. Ergeben sich unterschiedliche Werte, dann ist das Assembly unzulässig geändert worden und somit nicht mehr sicher. Der generierte Hash-Wert selbst ist für ein Assembly in jedem Fall identisch, und zwar unabhängig davon, wer die Anwendung bzw. Komponente selbst ausgeführt hat. Per Reflection können Sie die Beweiskraft eines Assemblies oder auch des Hosts, der die CLR initiiert, selbst zur Laufzeit abfragen.

Berechtigungsanforderungen und -sätze

Das .NET-Sicherheitssystem basiert, wie bereits erwähnt, auf den so genannten Berechtigungen. Berechtigungsanforderungen bestimmen, welche Rechte für die einwandfreie Ausführung eines Programms oder einer Komponente erforderlich sind. Berechtigungen werden für unsichere Aktionen angefordert. Dabei kann es sich um Zugriffe auf die Registrierdatenbank und das Dateisystem, auf Umgebungsvariablen sowie Server-Komponenten (z.B. Verzeichnisdienste, Ereignisprotokolle) oder um den Aufruf von unmanaged Code (Nicht-.NET-Code) handeln.

Die Berechtigungsanforderungen legen dabei die Ressourcen fest, auf die in einer Anwendung zugegriffen werden soll. Um beispielsweise Schreib- und Lesezugriff auf einen Datenträger zu erhalten, fordern Sie innerhalb einer .NET-Anwendung die Erlaubnis für FileIOPermission an. Eine Zusammenstellung der grundlegenden Codezugriffsberechtigungen entnehmen Sie der Tabelle im Download-Bereich.

Lassen die aktuellen Sicherheitseinstellungen die angeforderte Berechtigung nicht zu, wird bereits beim Ausführen der Anwendung eine Ausnahme erzeugt (Exception Handling). Die Ausnahme kann innerhalb des Assemblies direkt verarbeitet werden. Somit ist ein Programmentwickler in der Lage, bereits auf Quelltextebene auf die aktuellen Konfigurationseinstellungen zu reagieren.

Stack Walk – Speicherkontrolle inklusive

Mit Hilfe der Codezugriffssicherheit (CAS) wird sichergestellt, dass ausgeführte Assemblies und darüber nachgeladene Assemblies nur die Funktionen ausführen, zu denen sie auch berechtigt sind. Die Überprüfung der Berechtigungen neuer Methoden erfolgt durch den so genannten Stack Walk. Wird ein Assembly A3 durch A2 aufgerufen, das seinerseits durch A1 gestartet wurde und beinhaltet A3 eine Sicherheitsanforderung, so wird sichergestellt, dass jedes im Stapelspeicher verwaltete Assembly gleiche Berechtigungen besitzt. Nur dann wird der Aufruf der jeweiligen Methode tatsächlich ausgeführt.

Damit Programme mit dem Sicherheitssystem der CLR agieren, werden die Quelltexte der .NET-Programme und -Komponenten entsprechend mit Sicherheitsanweisungen bzw. -attributen ausgestattet, die die gewünschten Berechtigungen anfordern. Die Sicherheitsaufrufe können dabei je nach gewünschter Anforderung imperativ und/oder deklarativ erfolgen. Die deklarative Syntax zur Berechtigungsanforderung erfolgt durch Zuweisung von Sicherheitsattributen zu einem Klassenmodul oder auch zu speziellen Methoden einer Klasse.

Die Anforderungen der Berechtigungen auf Quelltextebene informieren die CLR über die Zulässigkeit von Anweisungen. Imperative Sicherheitsaufrufe werden hingegen durch die neue Instanzierung bestimmter Sicherheitsobjekte und den direkten Aufruf zugeordneter Methoden durchgeführt. Berechtigungsanforderungen werden jeweils auf den Gültigkeitsbereich eines Assemblies angewendet. Der Quellcode selbst legt fest, welche Anforderungen zur Ausführung erfüllt sein müssen und welche Funktionalitäten nicht zulässig sind. Die Auswertung der Sicherheitsanforderungen erfolgt bereits beim Laden eines Assemblies in den Speicher.

Berechtigungen zur Programmausführung

Mittels imperativer oder deklarativer Anweisungen bestimmte Berechtigungsanforderungen einer Anwendung oder Komponente (siehe oben) legen die zugehörigen Laufzeitanforderungen fest. Sie werden im Manifest des jeweiligen Assemblies abgelegt und beim Laden durch die CLR ausgewertet.

Entsprechend den Regeln der Sicherheitsrichtlinien werden einem Assembly Berechtigungen über ein Sicherheitsregelwerk (Security Policy) zugeteilt (vergleiche Abbildung). Die Sicherheitsregeln bestimmen, ob Funktionen innerhalb der Komponente ausgeführt werden können oder aber nicht. Die Berechtigungsanforderungen weisen dem Assembly also keine zusätzlichen Berechtigungen zu. Die resultierenden Berechtigungen sind in jedem Fall abhängig von der lokalen Verwaltungsrichtlinie.

Um Fehler in der späteren Ausführung von Programmen und Komponenten auszuschließen, sollten diese immer nur die Berechtigungen anfordern, die sie auch tatsächlich benötigen. Dies verhindert den Missbrauch und den Datenverlust durch Fehlfunktionen. Werden einer Komponente aufgrund der zugewiesenen Security Policy Programmfunktionen untersagt, ist es Aufgabe des Administrators die Sicherheitskonfiguration so zu ändern, das ein fehlerfreies Ausführen möglich ist. Alternativ kann allerdings auch in Kauf genommen werden, dass vereinzelte Funktionen auf dem jeweiligen Rechner nicht ausführbar sind.

Berechtigungsanforderungen offenlegen

Bleibt letztendlich zu klären, wie der Administrator die angeforderten Berechtigungen eines Assemblies offen legen kann, um gegebenenfalls erforderliche Anpassungen an der lokalen Verwaltungsrichtlinie vorzunehmen und einhergehend damit die Ausführbarkeit des jeweiligen Assemblies sicherzustellen. Das .NET Framework 1.x stellt dazu das gesonderte Hilfsprogramm permview.exe (Permission Request Viewer) bereit, mit dessen Hilfe Sie die angeforderten Berechtigungen anzeigen lassen. Geben Sie den Befehl permview unter Angabe des zu analysierenden Assemblies ein, nachdem Sie die SDK-Eingabeaufforderung über den entsprwechenden Startmenübefehl geöffnet haben.

Prompt>permview Suchpfad\Assemblyname.exe|dll [Return]

Daraufhin werden die Sicherheitseinstellungen angezeigt. Alternativ bestimmen Sie durch den Befehl in der Form

Prompt>permview /OUTPUT Pfad\Zieldatei.Dateikürzel Suchpfad\Assemblyname.exe|dll [Return]

eine Ausgabedatei, in der erweiterte Sicherheitsanforderungen abgelegt werden. Werden in einem Assembly keine Berechtigungsanforderungen gemacht, so liefert auch das Hilfsprogramm PermView keine Ergebnisse zurück.

Mit .NET 2.0 und höher wurde das Tool Permview.exe durch das alternative Programm Permcalc.exe ersetzt, das allerdings im Funktionsumfang von Permview.exe abweicht. Um entsprechende Informationen zu einem Assembly mit Permcalc.exe zu ermitteln, muss der gesonderte Kommandozeilenschalter –assembly gesetzt sein. Erweiterte Informationen zu Permcalc.exe und zur Sicherheit im .NET Framework gibt es im Internet (siehe Weblinks).

Als Buch zur Internet-Sicherheit sei das Werk .NET Framework Security der Autoren Brian A. LaMacchia, Sebastian Lange, Mathew Lyons, Rudi Martin und Kevin T. Price empfohlen (Addison Wesley, Pearson Education, ISBN 0-672-32184-X, ca. 790 Seiten).

(ID:2004956)