Softwareentwicklung mit .NET

Teil 7

.NET Security

Dr. Ralph Zeller

1

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)

2

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

3

vertrauenswürdiger Code



OS Security basiert auf Benutzerrechten



CLR Security erteilt Code Ausführungsrechte Trusted user !

Untrusted code Untrusted user Untrusted code Trusted user Trusted code !

Untrusted user Trusted code

4

partiell trusted Code Beispiel 1: File lesen

5

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

6

Permissions (Rechte)



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)

7

Per. schützen Ressourcen



FileIO



FileDialog



IsolatedStorage



Environment



Registry



UI



Printing



Reflection



Security



Socket



Web



DNS



OleDb



SQLClient



MessageQueue



EventLog

 

DirectoryServices

… erweiterbar

8

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 }

9

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();

10

Security Checks

 • • •

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

11

Stack walking

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

12

Stack Walk Modifikatoren



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

13

Security check

Beispiel 2: Stackwalk

14

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

15

Policy Levels



Policies sind auf verschiedenen Ebenen administrierbar

enterprise machine resultierendes Permission Set appdomain user 16

Code Gruppen



Jeder Policy Level ist ein Baum von Code Gruppen



Code Gruppen bestehen aus einer Bedingung und einem Permission Set

Code Gruppe

Bedingung?

P



Erfüllt ein Assembly die Bedingung, wird die Permission erteilt

17

Machine Level Policy

All



Local?

Full intranet?

intranet Internet?

Internet Restricted?

Execute Microsoft?

Full Network Network

enthält Permissions um auf Datenquellen im Netz zuzugreifen 18

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

19

Caspol.exe

Beispiel 3: caspol Stackwalk

20

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

21

Fragen?

Uff...

22