View
107
Download
2
Category
Preview:
Citation preview
.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 Permissionshö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
UserApplicationDomain
GrantedPermissionSet
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!
Recommended