.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!