.Net Security

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

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!

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

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

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

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

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

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

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

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

Codegruppen (2)

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

Zuweisen von Rechten (3)

Policy Enforcement implizit Stack Walk

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

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

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

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

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

Danke für die Aufmerksamkeit!