1 Softwareentwicklung mit.NET Teil 7.NET Security Dr. Ralph Zeller

2 Motivation  Verteilte Applikationen können Code dynamisch über das Internet laden und ausführen (mobiler Code)  Manipulierter Code kann Systeme und Daten beschädigen  Bisherige Security Mechanismen: Security bezieht sich auf User und Ihre Rollen Code wird mit Rechten des Users ausgeführt Beschränkter Zugriff auf Ressourcen (Verzeichnisse, Files, Konfiguration)

3 CLR Security  Rollen basierte Security Benutzer gehört zu einer Gruppe Benutzer muss sich authentifizieren Prinzipal Konzept (Gruppenrechte)  Code access security Zusätzlich zur Rollen basierten Security Bietet Schutz vor manipulierten Code  Security Modell basiert auf Permissions Code benötigt Rechte um Operationen auszuführen

4  OS Security basiert auf Benutzerrechten  CLR Security erteilt Code Ausführungsrechte vertrauenswürdiger Code Trusted user Trusted code Untrusted user Untrusted code Trusted user Untrusted code Untrusted user Trusted code !!

5 partiell trusted Code Beispiel 1: File lesen

6 Evidence Ursprungsnachweis  Information über ein Assembly (Code) Wer veröffentlichte das Assembly? Woher kommt das Assembly?  Beispiele für Evidence Zone (MyComputer, Intranet, Internet, Trusted, Untrusted) Site, URL oder Herkunftsverzeichnis Hash value Strong Name Applikation Verzeichnis Herausgeber Zertifikat

7  Permissions sind Objekte, die den Zugang zu bestimmten Ressource kontrollieren  Was wird kontrolliert? Dateisystem, Netzwerk, User Interface, Registry, Datenbank, Environment Variablen, …  Code kann Permissions anfordern (request)  Die CLR gewährt Permissions auf Anforderung, wenn der Aufrufer vertrauenswürdig ist (grant)  Permissions können von der aufrufenden Funktion angefordert werden (demand) Permissions (Rechte)

8 Per. schützen Ressourcen  FileIO  FileDialog  IsolatedStorage  Environment  Registry  UI  Printing  Reflection  Security  Socket  Web  DNS  OleDb  SQLClient  MessageQueue  EventLog  DirectoryServices  … erweiterbar

9 Deklarative Permissions  … über Attribute  Spezielle Permissions für Assembly, Klasse oder Methode Lower Lever Security überschreibt Higher Level Security!  Zur Ladezeit wird entschieden ob Permission gewährt wird using System.Security.Permissions; [FileIOPermissionAttribute(SecurityAction.Demand)] public static string ReadData() { // lese File ein } using System.Security.Permissions; [FileIOPermissionAttribute(SecurityAction.Demand)] public static string ReadData() { // lese File ein }

10 Imperative Permissions  … über expliziten Code  Erzeuge ein Permission Objekt und rufe seine Methoden auf  Schutz bezieht sich auf Methode  Zur Laufzeit wird entschieden ob Permission gewährt wird using System.Security.Permissions; String fullPath = Directory.GetFullPathInternal(fileName); FileIOPermission p = new FileIOPermission( FileIOPermissionAccess.Read, fullPath); p.Demand(); using System.Security.Permissions; String fullPath = Directory.GetFullPathInternal(fileName); FileIOPermission p = new FileIOPermission( FileIOPermissionAccess.Read, fullPath); p.Demand();

11  Applikationen umfassen mehrere Assemblies.exe Assembly Assemblies aus der Framework Class Library Fremde Library, Mobile Code, etc.  Wenn ein Assembly ein anderes aufruft wird Security Grenze überschritten  Vor Ausführung einer sensiblen Operation checkt die CLR den Call-Stack Kontrolle ob jedes Assembly am Call-Stack die nötigen Permissions hat Dieser Stack-walk heißt Demand Security Checks

12 Stack walking Methode M3 Methode M2 Methode M1 Methode M4 Call Stack wächst nach unten B2 B1 B3 B4 Jede Methode hat be- stimmte Berechtigungen Methode M4 fordert Permission P P P wird mit den Berechtigungen aller Aufrufer am Stack über M4 verglichen P P P

13  Modifikatoren überschreiben das Ergebnis des Stack-Walks  Assert Ich verbürge mich für meine Aufrufer. Permission nicht weiter prüfen Security Loch  Deny Permission wird explizit verweigert  PermitOnly Erlaubt Zugriff auf eine spezielle Ressource Stack Walk Modifikatoren

14 Security check Beispiel 2: Stackwalk

15 Policies  Policy bezeichnet Regeln, nach denen die CLR Permissions zuweist  Abhängig von der Evidence des Codes und dem Policy Level Enterprise, Machine, User, Application domain

16 Policy Levels  Policies sind auf verschiedenen Ebenen administrierbar enterprise user machine appdomain resultierendes Permission Set

17 Code Gruppen  Jeder Policy Level ist ein Baum von Code Gruppen  Code Gruppen bestehen aus einer Bedingung und einem Permission Set Bedingung? P Code Gruppe  Erfüllt ein Assembly die Bedingung, wird die Permission erteilt

18 Machine Level Policy intranet? Restricted? Execute Local? Full All  Microsoft? Full Internet? Internet Network Network enthält Permissions um auf Datenquellen im Netz zuzugreifen intranet

19 Policies administrieren  Command line Utility Caspol.exe  Konfiguration von Maschinen und User Policies zufügen, ändern und löschen von Code Gruppen Permissions und Permission Sets  Beispiel caspol –listgroups Caspol –resolvegroup assembly.dll Caspol –resolveperm assembly.dll caspol –machine –addfulltrust assembly.dll caspol –machine –ag 1.1 –zone Internet execution caspol –listgroups Caspol –resolvegroup assembly.dll Caspol –resolveperm assembly.dll caspol –machine –addfulltrust assembly.dll caspol –machine –ag 1.1 –zone Internet execution

20 Caspol.exe Beispiel 3: caspol Stackwalk

21 Mscorcfg.msc  Gaphisches Benutzer Interface Microsoft Management Konsole Snap-In  Administriert Security Policies Änderungen an Code Gruppen und Permission Sets Auf Enterprise, Machine und User Level

22 Fragen? Uff...