.Net Security. Motivation Rad nicht neu erfinden -> Nutzung der Sicherheitsfunktionen des Betriebssystems (zB Encryption, Authentifizierung,...) Zusätzlich.

Präsentation zum Thema: ".Net Security. Motivation Rad nicht neu erfinden -> Nutzung der Sicherheitsfunktionen des Betriebssystems (zB Encryption, Authentifizierung,...) Zusätzlich."—  Präsentation transkript:

1 .Net Security

2 Motivation Rad nicht neu erfinden -> Nutzung der Sicherheitsfunktionen des Betriebssystems (zB Encryption, Authentifizierung,...) Zusätzlich eigenes Sicherheitssystem: CAS Ziele von Code Access Security: –Rechte für Code (nicht User) vergeben –feinere Granularität (verschiedene Rechte für Codestücke einer Anwendung) –sichere Ausführung von Code von verschiedenen Quellen

3 Role-based Security In den meisten Betriebssystemen verwendet Sag mir, wer du bist, und ich sag dir, was du darfst Principal = Identity + Roles -> Beispiel1 Oft problematisch -> Code-based Security!

4 Code-based Security Auch Evidence-based Security Sag mir, woher du kommst, und ich sag dir, was du darfst Rechte werden für jedes Assembly einzeln vergeben -> feine Granularität Kann erweitert und modifiziert werden -> individuelle Anpassung

5 Permissions Permission: Objekt, das Rechte repräsentiert, auf eine geschützte Ressource zuzugreifen Permission Set: Menge von Permissions höchstens ein Objekt pro Permissiontyp -> Vereinigung der Objekte

6 Zuweisung von Rechten (1) Evidence + Security Policy = Permission Set

7 Evidence Beschreibt Herkunft des Assemblies 7 vordefinierte Evidence-Typen Woher wurde Code geladen? URL, Site, Zone, ApplicationDirectory Wer hat Code geschrieben? StrongName, Publisher Allgemein: Hash

8 Security Policy Regeln zur Rechtevergabe Security Manager bestimmt anhand von Security Policy und Evidence die Rechte eines Assemblies Wird auf jede Policy Ebene angewandt

9 Policy Levels (1) EnterpriseMachine User Application Domain Granted Permission Set

10 Policy Levels (2) Jedes Policy Level besteht aus: –Hierarchie von Codegruppen (baumartig) –Liste mit Named Permission Sets –Liste mit Policy Assemblies Durchschnitt der Permission Sets aller Ebenen = granted Permission Set

11 Codegruppen (1) Jede Codegruppe besteht aus: –Membership Condition –Permission Set –Attribute (LevelFinal, Exclusive) Permission Set eines Policy Levels = Vereinigung der Permission Sets aller passender Codegruppen

12 Codegruppen (2)

13 Zuweisung von Rechten (2) mögliche Rechte != erhaltene Rechte Ziel: nur minimale Menge von Permissions anfordern –RequestMinimum –RequestOptional –RequestRefuse Zugewiesene Permissions: (MaxGrant (ReqMin ReqOpt)) - ReqRefuse

14 Zuweisen von Rechten (3)

15 Policy Enforcement implizit Stack Walk

16 Policy Enforcement explizit (1) Demand, Link-Demand Assert Deny PermitOnly Immer nur eine Permission kann jeweiligen Zustand annehmen, bei mehreren Permissions -> Permission Set

17 Policy Enforcement explizit (2) Prioritäten: Deny – Assert – PermitOnly Code, der Assert aufruft, muss spezielle Permission haben RevertAssert, RevertDeny,... Keine unnötigen Stack Walks! Beispiel2

18 Policy Enforcement explizit (3) Imperativ: dynamisch (Demand, Assert,...) Deklarativ: statisch (benutzerdefinierte Attribute) -> Beispiel3

19 Bedeutung für Praxis (1) Meist keine explizite Verwendung der CAS nötig aber: SecurityExceptions abfangen! Beim Zugriff auf geschützte Ressourcen ohne Umweg über Bibliotheken Defaulteinstellungen modifizierbar

20 Bedeutung für Praxis (2) Selbst definierbar: –Evidence-Typen –Permissions –Permission Sets Tools für Konfigurationen: –mscorcfg.msc –caspol.exe

21 Danke für die Aufmerksamkeit!