Security.NET Was darf mein Code?

Präsentation zum Thema: "Security.NET Was darf mein Code?"—  Präsentation transkript:

1 Security.NET Was darf mein Code?

2 Security.NET Was darf mein Code? DEV-3
Michael Willers

3 In diesem Vortrag... Warum ein neues Modell? Wie funktioniert es?
Wie setzt man es in der Praxis ein?

4 Warum ein neues Modell? Code kann dynamisch über das Internet geladen und ausgeführt werden mobiler Code Aber: Sicherheitssysteme basieren auf Benutzern! Manipulierter Code kann Systeme und Daten beschädigen

5 Was ist Code Access Security?
Die Common Language Runtime bringt ein neues Sicherheitsmodell mit, das auf den Merkmalen (Evidence) des geladenen Codes basiert Es ergänzt die Sicherheitsmechanismen des Betriebssystems und wird mit Code Access Security bezeichnet

6 Mobiler Code 

7 Evidence (Codemerkmale)
Informationen über ein Assembly (Code) Wer veröffentlichte das Assembly? Woher kommt das Assembly? Beispiele für Evidence Anwendungsverzeichnis Strong Name X.509-Zertifikat URL ...

8 Permissions Permissions sind Objekte, die den Zugang zu Systemressourcen kontrollieren Was wird kontrolliert? Dateisystem, Netzwerk, User Interface, Registry, Datenbank, Environment Variablen, …

9 Permissions Request Demand Grant Code kann Permissions anfordern
Permissions können von der aufrufenden Funktion angefordert werden Grant Die CLR gewährt Permissions, wenn der Aufrufer vertrauenswürdig ist

10 In der Übersicht... Evidence Membership Condition Membership Condition
Code Group Code Group Permission Set Permission Set P P P P P P P P

11 Auswerten von Code Groups
1. 1.1 1.2 1.1.1 1.1.2 1.2.1 1.2.2.

12 Sicherheitsrichtlinien (Policies)
Enterprise Machine resultierende Rechte Appdomain (per Code) User

13 Mobiler Code 

14 Voraussetzungen deklarieren
Assembly-Ebene SecurityAction.RequestMinimum SecurityAction.RequestOptional SecurityAction.RequestRefuse Klassen- und Methodenebene SecurityAction.Assert SecurityAction.Demand „Keep Admins happy“ Deklationen sind Metadaten!

15 Voraussetzungen deklarieren
Problem: derzeit keine Variablen zur Laufzeit Permission State muss komplett zur Compile-Zeit angegeben werden Achtung: Änderung modifiziert das Assembly! Assembly muss neu signiert werden!!! Also vor der Auslieferung bedenken

16 Der Stackwalk Sämtliche Aufrufer auf dem Stack müssen diese Permission haben 3 P 1 Jeder Aufrufer hat eigene Rechte R1 R2 R3 R4 Methode 3 Methode 2 Methode 1 Methode 4 Methode 4 fordert Permission P an 2 P

17 Kontrolle über den Stackwalk
Assert Stackwalk wird abgebrochen Deny Zugriff auf Ressource wird grundsätzlich verweigert Test von Permissions, die nicht „erlaubt“ sind PermitOnly Umkehrung von Deny Gezielter Test einer einzelnen Permission Stackwalk wird nur fortgesetzt, wenn diese Permission vorhanden ist

18 Vorsicht bei Assert Assert kann Löcher ins Sicherheitssystem bringen
Assert nur nach genauer Überlegung in ein System einführen „lange Aufrufketten“ beim Stackwalk bei Aufrufen von Unmanaged Code Assert sobald wie möglich wieder per RevertAssert aufheben! Assert kann von Administratoren unterbunden werden Code läuft plötzlich nicht mehr

19 Demand und LinkDemand... A Fully Trusted A Fully Trusted B
C Partially Trusted D Fully Trusted D Fully Trusted (Link-) Demand for FullTrust E Fully Trusted E Fully Trusted

20 Demand und LinkDemand...

21 LinkDemand Sicherheitscheck beim Übersetzen eines Assemblies
Nur deklarativ (per Attribut) Nur direkter Aufrufer wird geprüft Kein vollständiger Stackwalk daher mögliche Sicherheitlücke !!! also nur nach genauer Überlegung benutzen Exception, wenn Link nicht möglich

22 AllowPartiallyTrustedCallers
CLR führt für Strong Named Assemblies automatisch einen LinkDemand für FullTrust aus Verhindern von „Luring Attacks“ Problem: aufrufende Assemblies, die kein FullTrust haben können dieses Assembly nicht benutzen Exception mit der Meldung “Request Failed” deutet auf dieses Problem hin

23 AllowPartiallyTrustedCallers
Lösung: LinkDemand abschalten Attribut AllowPartiallyTrustedCallers auf Assembly-Ebene hinzufügen Sinngemäß hat dies folgende Bedeutung: „Ich, der Entwickler, habe den Code in diesem Assembly nach bestem Wissen und Gewissen geprüft und bin mir absolut sicher, dass keine Luring Attacks möglich sind!“ Lassen Sie äußerste Vorsicht beim Einsatz dieses Attributs walten!!!

24 StrongNameIdentityPermission
Bestimmte Assemblies sollen nicht von jedem aufgerufen werden können Problem: CLR prüft standardmäßig nicht, von welchem Assembly aus ein Stück Code aufgerufen wird

25 StrongNameIdentityPermission
Einfache Lösung: Explizite Definition per LinkDemand Attribut StrongNameIdentityPermission hinzufügen Mögliche Sicherheitslücke, da Sicherheitscheck nur beim Übersetzen erfolgt Bessere Lösung: Eigene Ressourcen werden durch eigene Permissions geschützt (!!!)

26 Tipps Vermeiden Sie LinkDemands grundsätzlich!
Vermeiden Sie Assert wann immer es irgendwie geht! Wenn Sie den Zugriff auf eigene Ressourcen kontrollieren wollen, sollten Sie eine eigene Permission implementieren

27 Richtliniensystem erweitern

28 Richtliniensystem erweitern
Custom Permissions Zugriff auf Systemressourcen, die standardmäßig nicht geschützt sind Custom Code Groups und Membership Conditions Implementieren eigener Logik für Code Groups Custom Evidence Eingebettet im Assembly vom CLR-Host definiert (à Yukon)

29 Full Trust Assemblies Assemblies, die für die Funktionalität der Zugriffssicherheit sorgen Permission-Klassen Alle Parametertypen der Permission-Klassen MembershipConditions Alle Klassen, die das Richtliniensystem zur Evaluierung der Rechte eines Assemblies benötigt

30 Tipps Setzen Sie bei allen Assemblies, die Sie ausliefern Strong Names ein (à Sicherheit)! Definieren Sie eine eigene Sandbox für Ihren Code und nutzen Sie dabei den Strong Name oder ein Zertifikat als Merkmal (à Evidence)! Achten Sie auf mögliche Sicherheitslücken (à Assert und LinkDemand)!!!

31 Security.NET - Was darf mein Code?
Zusammenfassung Code Access Security bietet ein Sicherheitsmodell für mobilen Code, das auf dem Betriebssystem aufsetzt Code wird in einer Sandbox ausgeführt, die selektiven Zugriff auf Systemressourcen erlaubt Der Administrator definiert über Sicherheitsrichtlinen, welche Zugriffe erlaubt sind

32 Danke für Ihre Aufmerksamkeit


33 Fragen!? Uff...

34 Mehr Informationen MOC 2350: Securing and Deploying Microsoft .NET Assemblies Don Box, Security in .NET msdn.microsoft.com/msdnmag/issues/02/09/SecurityinNET/default.aspx M. Howard, D. LeBlanc, Writing Secure Code, Microsoft Press

35 Über den Referenten Michael Willers ist Software-Architekt und Trainer. Er berät Projektverantwortliche und Softwareentwickler bei Design und Implementierung von Lösungen für die Microsoft .NET Plattform. Darüber hinaus ist Michael Willers Mitglied in verschiedenen Fachbeiräten und Lehrbeauftragter für den Themenbereich Softwareentwicklung an mehreren Fachhochschulen und Universitäten in Deutschland. Er ist Initiator und Gründer des msdn TechTalk von Microsoft und war zuvor lange Jahre als Entwickler und Projektleiter für namhafte Unternehmen, u.a. Microsoft Deutschland, tätig. Sie erreichen Ihn per an oder über seine Website

36 Publikationen des Referenten
Security.NET - Was darf mein Code? Publikationen des Referenten Willers, Michael: Microsoft‘s Weg zu .NET c‘t Magazin für Computertechnik, Nr. 6/2001, S , Februar 2001 Willers, Michael: ".NET Remoting“ - Lego-Baukasten für verteilte Anwendungen OBJEKTspektrum, Nr. 3/2002, S. 83, Mai/Juni 2002 Willers, Michael: Wird alles anders? - Asynchrone Methodenaufrufe in .NET OBJEKTspektrum, Nr. 2/2002, S. 68, März/April 2002 Willers, Michael: Die ".NET Common Language Runtime": Überblick und Einsteig OBJEKTspektrum, Nr. 4/2001, S , Juli/August 2001 Willers, Michael: "Microsoft .NET" - das programmierbare Web OBJEKTspektrum, Nr. 6/2000, S , November/Dezember 2000 Willers, Michael: "OLE DB" - ein Generalschlüssel für Datenzugriffe? OBJEKTspektrum, Nr. 2/2000, S , März/April 2000 Willers, Michael: So richten Sie IIS Anwendungen automatisch ein System Journal, Nr. 5/2000, S , September/Oktober 2000 Willers, Michael: Marshaling auf der Basis von Typbibliotheken System Journal, Nr. 6/1999, S , November/Dezember 1999 Mehr Informationen unter in der Rubrik Publikationen.

37 Glossar CLR - Common Language Runtime: Laufzeitumgebung des .NET Frameworks. Sie muss installiert sein, damit ein .NET-Programm ausgeführt werden kann. Sie ist die einheitliche Laufzeitumgebung aller .NET-Programmiersprachen. Assembly: Softwarekomponente im .NET Framework. Jede .NET-Anwendung besteht aus einem Assembly und jede Assembly ist eine Komponente im Sinne objektorientierter Softwarekomponenten. Wiederverwendung, Sicherheit, Versionierung und Deployment finden im .NET Framework auf der Basis von Assemblies statt. Strong Name: garantiert einen eindeutigen Namen und die Integrität (Unversehrtheit) einer Assembly. Er basiert auf einem Public Key-Verfahren, bei dem der endgültige Assembly-Name aus dem öffentlichen Schlüssel und dem einfachen Namen (z.B. MyTestAssembly) gebildet wird. Zusätzlich wird die Assembly mit dem privaten Schlüssel signiert. Durch die Umkehrung der Signatur mit Hilfe des öffentlichen Schlüssels kann der Empfänger einer Assembly sicher feststellen, ob die Datei auf ihrem Weg vom Autor zu ihm verändert wurde. Luring Attack: der Versuch, eine Aktion auszuführen zu der man nicht die notwendigen Rechte besitzt. Zu diesem Zweck versucht man jemanden, die diese Rechte hat, zur Ausführung zu bewegen. Sandbox: abgeschottete Umgebung mit einem exakt definierten Sicherheitskontext, in der Code ausgeführt wird

38 Glossar Evidence: Codemerkmale, die von den Sicherheitsrichtlinien zur Gewährung bestimmter Permissions herangezogen werden Bedingung (membership condition): Objekt, welches über das Vorhandensein spezifischer Evidence Auskunft gibt Code Group: Objekt, welches eine Bedingung mit einem Satz von Permissions verknüpft Permission Set: Zusammenfassung von einzelnen Permissions zu einer Gruppe, vergleichbar mir Benutzern und Benutzergruppen Permission: Objekt, welches Zugriffsrechte für eine Ressource oder Identität repräsentiert deklarative Sicherheitsprüfung: Prüfung anhand von in Metadaten enthaltenen Sicherheitsinformationen imperative Sicherheitsprüfung: Prüfung nach Aufruf einer Sicherheitsmethode in geschütztem Code Rechteanforderung (permission demand): fordert Überprüfung auf ausreichende Rechte durch den aufrufenden Code Sicherheitsrichtlinien (policy): hierarchischer Satz von Vorschriften zur Einschränkung der Rechte, die verwaltetem Code gewährt werden Stackwalk: systematische Überprüfung der Rechte aufrufender Funktionen auf dem call stack im Falle einer Rechteanforderung

39 Security.NET - Was darf mein Code?
Microsoft‘s Vision Empower people software through great any time, any place, and on any device. Final Slide #4 / Schlußfolie 4 = Mission Statement Please include the Microsoft Mission Statement as last and final slide in all presentations