Zusammenfassung der Änderungen in Bezug auf die Codezugriffssicherheit
In .NET Framework, Version 4 wurde die Codezugriffssicherheit (Code Access Security, CAS) zum Zweck der Vereinfachung des Sicherheitssystems erheblichen Änderungen unterzogen. In früheren Versionen von .NET Framework wurden die Rechte einer verwalteten Anwendung durch Regeln von Sicherheitsrichtlinien bestimmt, über die computerweit die Laufzeiteinstellungen eingerichtet wurden. Ab .NET Framework 4 gilt jedoch Folgendes:
Sicherheitsrichtlinien sind nicht mehr gültig. Berechtigungen werden jedoch weiterhin verwendet, lediglich das Richtliniensystem wurde abgeschafft.
Die Zugriffsrechte für Anwendungen werden durch zwei Faktoren bestimmt: Berechtigungen (der von der Anwendungsdomäne festgelegte Berechtigungssatz) und Transparenz. Alle teilweise vertrauenswürdigen Anwendungen werden als transparent klassifiziert. Transparente Anwendungen sind für die Sicherheit nicht relevant. Die Transparenz wurde erstmals für Microsoft Silverlight verwendet und nun auf alle gehosteten Umgebungen erweitert.
Desktopbrowsern und lokalen Intranetanwendungen wird volle Vertrauenswürdigkeit zugewiesen.
.gif "Wichtiger Hinweis") Wichtig |
|---|
Die hauptsächliche Änderung im Vergleich zu CAS besteht in der Abschaffung der Sicherheitsrichtlinien.CAS selbst wurde nicht abgeschafft, dies betrifft lediglich die Verwendung von Richtlinien (und einigen Berechtigungsanforderungen). |
Dieses Thema gibt eine kurze Übersicht über die Änderungen von CAS in .NET Framework 4. Weitere Informationen finden Sie unter Änderungen der Sicherheit in .NET Framework 4.
Sandkasten und Berechtigungsmodell
In der folgenden Liste ist das Vertrauensstellungsmodell für Desktop- und gehostete Anwendungen in .NET Framework 4 beschrieben. Weitere Informationen finden Sie unter Änderungen der Sicherheit in .NET Framework 4.
Desktopanwendungen. Wie in früheren Versionen von .NET Framework wird verwalteten Anwendungen auf dem Desktop volle Vertrauenswürdigkeit gewährt, sofern sie nicht aus dem Internet heruntergeladen wurden. Anwendungen in Freigaben im lokalen Intranet wird ebenfalls volle Vertrauenswürdigkeit gewährt. Sie können keine Richtlinien mehr verwenden, um Berechtigungen für eine Anwendung anhand des Ordners auf der lokalen Festplatte einzuschränken.
Gehostete Anwendungen. Anwendungen, die in einem Sandkasten ausgeführt werden (beispielsweise Silverlight-basierte Anwendungen), wird ein eingeschränkter Satz von Berechtigungen gewährt, die die Computerressourcen bestimmen, auf die sie zugreifen können (z. B. die Dateien, die verwendet werden dürfen). Sandkästen bieten die Möglichkeit, einige Assemblys im Sandkasten als teilweise vertrauenswürdig festzulegen und andere als voll vertrauenswürdig. Teilweise vertrauenswürdigen Assemblys werden bestimmte Berechtigungen gewährt, die von der Anwendungsdomäne (System.AppDomain) bestimmt werden, von der der Sandkasten erstellt wurde. Ein Teil des voll vertrauenswürdigen Codes in den voll vertrauenswürdigen Bibliotheken kann von teilweise vertrauenswürdigem Code aufgerufen werden. Dieser vertrauenswürdige Code kann geschützte Ressourcen auf dem Computer aufrufen. Allerdings müssen öffentlich verfügbare, voll vertrauenswürdige Typen und Member, die geschützte Ressourcen aufrufen können, zuvor einer Sicherheitsüberprüfung unterzogen werden. Diese Member werden, wie im nächsten Abschnitt beschrieben, als sicherungskritisch klassifiziert. Sie können von teilweise vertrauenswürdigem (transparentem) Code aufgerufen werden und selbst kritischen Code aufrufen.
Sicherheitstransparenz
Die Sicherheitstransparenz bildet den Unterschied zwischen sicherheitsrelevantem Code und nicht sicherheitsrelevantem Code. Sie wurde in .NET Framework, Version 2.0 eingeführt, um die Sicherheitsüberwachung zu vereinfachen, indem Code, der sicherheitsrelevante Aktionen ausführen musste, als sicherheitskritisch gekennzeichnet wurde. Daher war für jeglichen Code, der nicht sicherheitskritisch war (also transparenten Code), keine gründliche Überprüfung erforderlich. In diesen früheren Versionen von .NET Framework wurde die Transparenz nur von Microsoft-Code verwendet.
In .NET Framework 4 wurde dieses Modell erweitert, und die Regeln wurden strikter gestaltet, sodass es sich bei der Sicherheitstransparenz nun um ein Erzwingungsmodell handelt. In diesem verbesserten Modell kann sicherheitsrelevanter Code, der von teilweise vertrauenswürdigen Anwendungen aufgerufen werden kann, leicht identifiziert werden. Damit wird auch die zu überwachende Oberfläche weiter verkleinert.
In der folgenden Tabelle sind die Kategorien für Transparenz und die zugehörigen Attribute für das Kennzeichnen des Codes angegeben.
Sicherheitskategorie |
Attribut |
Beschreibung |
|---|---|---|
Transparent |
Code, der keine inhärent sicherheitsrelevante Aktion ausführt. |
|
Kritisch |
Code, der beliebige Aktionen ausführen, jedoch nicht von teilweise vertrauenswürdigen Anwendungen aufgerufen werden kann. |
|
Sicherheitskritisch |
Code, der beliebige Aktionen ausführen und von teilweise vertrauenswürdigen Anwendungen aufgerufen werden kann. Dies ist die Ebene für sicheres Aushandeln. Ihr Zweck besteht in der Ausführung ordnungsgemäßer Sicherheitsüberprüfungen und der Validierung vor dem Aufruf kritischen Codes. |
Transparenter Code kann unabhängig von den gewährten Berechtigungen keine der folgenden Aktionen ausführen:
Einschließen von nicht überprüfbarem Code.
Verwendung des Plattformaufrufs.
Ausführen von Assert-Vorgängen.
Aufrufen von kritischem Code.
Ableiten von kritischem Code.
Aufrufen von Code an, der durch einen LinkDemand geschützt ist (das heißt Code, der als kritisch behandelt wird).
Wenn der Code versucht, diese Regeln zu verletzen, werden Ausnahmen ausgelöst (auch, wenn der Code als voll vertrauenswürdig festgelegt ist). Weitere Informationen finden Sie unter Änderungen der Sicherheit in .NET Framework 4.
Beachten Sie, dass die Sicherheitsempfindlichkeit in der Common Language Runtime (CLR) in Form von Aktionen definiert ist, die für transparenten Code unzulässig sind. Das Transparenzmodell schützt nicht vor szenariospezifischen Sicherheitsverletzungen, z. B. dem Speichern von Kennwörtern in Feldern.
Funktionsweise des Sicherheitsmodells
Jede AppDomain verfügt über einen zugeordneten Berechtigungssatz, der in einem gehosteten Szenario vom Host definiert wird. (Bei nicht gehostetem Code ist als Berechtigungssatz volle Vertrauenswürdigkeit festgelegt.)
Teilweise vertrauenswürdiger Code ist immer transparent. Deshalb kann er keine Aktionen ausführen, die für transparenten Code nicht zulässig sind (siehe Transparenz).
Standardmäßig ist voll vertrauenswürdiger Code als kritisch festgelegt, sofern er nicht als transparent gekennzeichnet wurde. Wenn eine Desktopanwendung als transparent gekennzeichnet ist, kann sie keinen kritischen Code aufrufen, obwohl sie als voll vertrauenswürdig festgelegt ist.
Bibliotheken können vom Host und von .NET Framework für teilweise vertrauenswürdigen Code verfügbar gemacht werden. Diese Bibliotheken enthalten eine Mischung von transparentem, kritischem und sicherungskritischem Code.
Vor Verwendung kritischer Funktionen muss sicherungskritischer Code entsprechende Berechtigungen anfordern. Zum Beispiel erfordert die File.Open-Methode vor dem Öffnen einer Datei FileIOPermission.
Vor und nach Aufrufen kritischer Funktionen müssen zudem für sicherungskritischen Code alle weiteren Überprüfungen und Validierungen ausgeführt werden. Möglicherweise müssen z. B. Ausnahmen und Meldungen gefiltert werden, bevor sie an teilweise vertrauenswürdigen Code übergeben werden.
Kritischer Code muss die Berechtigungen anfordern, die beim Aufruf durch teilweise vertrauenswürdigen Code erforderlich werden, da von kritischem Code Aktionen ausgeführt werden können, die für teilweise vertrauenswürdigen Code unzulässig sind.
Siehe auch
Konzepte
Änderungen der Sicherheit in .NET Framework 4