Systemschutz mit Code Access Security

Wenn Ihr Code versucht, ohne Erlaubnis auf geschützte Systemressourcen zuzugreifen, dann meldet der Exception Manager der CLR eine SecurityException (Sicherheitsausnahme). Diese kann man mit einem Try/Catch/Finally-Block auffangen und verarbeiten.
Auch während der Laufzeit kann man den Zugang zu geschützten Ressourcen kontrollieren, indem man die definierten Berechtigungsklassen (z.B. WebPermission, SocketPermission usw.) nutzt. Jede dieser Klassen bietet Deny- (Zugang verwehrt) und PermitOnly- (nur Berechtigung) Methoden, um Zugangsberechtigungen während der Laufzeit zu unterstützen.

Wenn die Deny-Methode einer Berechtigungsklasse aktiviert wird, dann wird die CLR jeglichem Folge-Code, der auf der assoziierten Berechtigung basiert, den Zugang zu geschützten Systemressourcen verweigern. Um die Deny-Beschränkung aufzuheben, muss der Code die RevertDeny-Methode (Aufheben der Zugangsverweigerung) benutzen. Statt die Deny-Methode einer Berechtigungsklasse zu benutzen um festzulegen, auf welche Ressourcen der Code zugreifen darf, kann man die PermitOnly-Methode nutzen. Wenn die PermitOnly-Methode genutzt wird, dann kann keine höhere Erlaubnis erteilt werden, als mit der derzeitigen Vertrauenswürdigkeitsstufe möglich ist. Wenn die CLR z.B. feststellt, dass ein Code aus dem Internet kommt und deshalb den Daten, die im Browser-Cache gespeichert sind, Read-Only-Status zuweist, dann kann das Programm nicht PermitOnly benutzen, um dem Code Zugang zur Festplatte zu gewähren. Wenn PermitOnly benutzt wird, dann kann nur auf jene geschützten Ressourcen zugegriffen werden, die durch die Methode spezifiziert werden – wenn die CLR keine Security-Exception melden soll. Wie die RevertDeny-Methode macht RevertPermitOnly die Auswirkungen eines vorherigen PermitOnly-Aufrufs rückgängig.

Berechtigungsgrenzen festlegen

Weil Anwendungen, die mit dem .NET Framework entwickelt wurden, aus einer Vielzahl von Komponenten bestehen, ist es wahrscheinlich, dass, wenn die CLR wirklich einmal einen Code ausführt, der auf geschützte Ressourcen zuzugreifen versucht, dieser Versuch tief aus einem Aufrufstapel (Call Stack) kommt. An diesem Punkt stellt die CLR sicher, dass jeder Aufrufer in der Aufruffolge die notwendigen Berechtigungen hat, um die angeforderten Operationen auszuführen – was man auch als „Walking the Stack“ („den Stapel ablaufen“) bezeichnet. Jede Komponente in einem Stack besitzt einen zugehörigen Stack Frame, der die zugewiesene Vertrauenswürdigkeitsstufe enthält. Wenn irgendeine dieser Komponenten nicht die notwendigen Berechtigungen hat, um auf eine geschützte Ressource zuzugreifen, dann wird die Operation nicht erfolgreich sein und eine Security-Exception gemeldet. Das bedeutet auch, dass die CLR den Stack jedes Mal abläuft, wenn eine Operation auf eine geschützte Ressource zugreifen will. Dadurch, dass die Sicherheit für jede Komponente überprüft wird, kann die CLR die Situation vermeiden, dass eine aufgerufene Komponente versucht, die Vertrauenswürdigkeit des Aufrufers auszunutzen. Leider hat diese Vorgehensweise auch den potentiellen Nachteil, den Rechenaufwand erheblich zu vergrößern.

Lösungen zu entwickeln, die diese Möglichkeiten von Code Access Security nutzen, erfordert die Fähigkeit, Sicherheit gegen Performance abwägen zu können. Richtlinien, wann and wie Code Access Security einzusetzen ist und wie lokale Vertrauenswürdigkeitsstufen zu wahren sind, erleichtern es, hier die richtige Balance zu finden.