Security .Net
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)
Enterprise Machine
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)) -
Zuweisen von Rechten (3)
Policy Enforcement implizit
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
