Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Security.NET Was darf mein Code?. Security.NET Was darf mein Code? DEV-3 Michael Willers"—  Präsentation transkript:

1 Security.NET Was darf mein Code?

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

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

4 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 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 6 Mobiler Code Mobiler Code

7 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 8 Permissions Permissions sind Objekte, die den Zugang zu Systemressourcen kontrollieren Was wird kontrolliert? Dateisystem, Netzwerk, User Interface, Registry, Datenbank, Environment Variablen, …

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

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

11 11 Auswerten von Code Groups

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

13 13 Mobiler Code Mobiler Code

14 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 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 16 Der Stackwalk Methode 3 Methode 2 Methode 1 Methode 4 Methode 4 fordert Permission P an 2 P 2 1 Jeder Aufrufer hat eigene Rechte R1 R2 R3 R4 1 Sämtliche Aufrufer auf dem Stack müssen diese Permission haben 3 P P P 3

17 17 Kontrolle über den Stackwalk Assert Stackwalk wird abgebrochen Deny Stackwalk wird abgebrochen 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 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 19 Demand und LinkDemand... A Fully Trusted B Fully Trusted D Fully Trusted E Fully Trusted A Fully Trusted C Partially Trusted D Fully Trusted E Fully Trusted (Link-) Demand for FullTrust

20 20 Demand und LinkDemand...

21 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 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 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 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 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 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 27 Richtliniensystem erweitern

28 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 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 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 31 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 32 Danke für Ihre Aufmerksamkeit

33 33 Fragen!? Uff...

34 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 #pd

35 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 36 Publikationen des Referenten Willers, Michael: Microsofts Weg zu.NET ct 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 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 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 39 Empower people through software any time, any place, and on any device. great Microsofts Vision


Herunterladen ppt "Security.NET Was darf mein Code?. Security.NET Was darf mein Code? DEV-3 Michael Willers"

Ähnliche Präsentationen


Google-Anzeigen