DEV240 Fundamentals of Code Access Security Sebastian Lange Program Manager Common Language Runtime Microsoft Corporation

Agenda Code Access Security (CAS) Design Goals Relationship to Windows OS Security CAS Infrastructure Verification and Validation Evidence Policy Permissions Enforcement

What is a Security System? Main Purpose: to protect a resource from illicit access or use Primary security identity System grants rights, enforces against specific identities Authentication Determining who is trying to gain access Authorization Granting rights to access resources Enforcement System Enforces the rights given

Example: Windows Security Primary Security Identity: User identity (or user role) Authentication: User supplies login credentials Authorization: User context is granted rights to access system objects Enforcement: OS gates access to system objects (File, Registry Key, …). Think ACL’s.

Code Access Security – A New Paradigm Primary Security Identity: Code (Assembly) Authentication: Information collected about code (Evidence) Authorization: Code identity based policy system grants rights to access resources Enforcement: Verification, Validation, Permission Demands, Stackwalks

Code Access Security Design Goals Robust security system for partially- trusted, mobile code Adds on to user-level security from OS Security out of the box Default Policy is conservative Required for end users and some Admins All code from Internet, Intranet, File Shares, … runs with restricted privileges

Code Access Security Design Goals Make it easier for… Developers to write secure libraries and applications As much burden as possible on the system Easy to perform security checks in code Administrators to express their policies Fine-grained authorization model System is completely extensible End users to work securely Minimal run-time security decisions (end-user UI by default)

CAS Infrastructure Validation Ensures correctness of file format Verification Ensures Type Safety Policy System Assigns trust to an assembly Enforcement Shared Library authors protect access to resources CLR enforces protection through stackwalks

Validation Checks Correctness of the PE file Validates image against PE spec Meta Data is checked MD layout validation: i.e pointers have valid destinations Semantic checks: i.e. Checking for circular inheritance IL stream is checked All instructions are valid and well-formed Semantic checks: i.e JMP’s stay within IL stream

Verification Enforces rules on code Ensures that Security can be enforced Verification rules are safe, may falsely reject Code is verified to be memory type safe Only access objects via well-defined interfaces No unsafe casts, no access beyond array bounds No stack underflow/overflow conditions Helps reduce buffer overruns

Verification Occurs during JIT Compilation Verifiability depends on the language compiler Visual Basic®.NET C# verifiable (except C# “unsafe” keyword) C++ is generally not verifiable Addressed in future release

Evidence Descriptive data about an assembly URL of origin, site, zone Strong Name signature, Authenticode signature, hash Host-defined Basis for assigning security rules Computed at load time of assembly by CLR Hosts can add their own evidence See System.Security.Policy.Evidence

CAS Policy Set of rules that assign trust to an assembly Specified by Administrator using.NET Configuration Tool Input: Data describing an assembly (Evidence) location, digital signature, hash, “host-defined” Output: Set of rights to access protected resources (Permissions) e.g File Permission, Registry Permission

CAS Policy Composed of “Code Groups” Membership Condition Permission Set Organized into a Hierarchy Multiple, Ordered Policy Levels Enterprise, Machine and User Final Output: Intersection of permissions granted by each level Result: Most restrictive wins Stored as XML files on disk See System.Security.Policy

CAS Policy System PolicyEvaluator Assembly A2 SecurityPolicy Evidence G2 Host GrantedPermissions

Default CAS Policy demo demo

Permissions Permissions represent the right to interact with a given resource Permission to access a resource demanded programmatically Output of Security Policy Implemented as Managed Classes See System.Security.Permissions, System.Security.CodeAccessPermission

Example Permissions FileIO Registry FileDialog Environment IsolatedStorage UI Printing Reflection Security Socket Web DNS OleDb SQLClient MessageQueue EventLog DirectoryServices … extensible Execute, Skip Verification, Call unmanaged code, Supply custom evidence

Permission Enforcement Permission “Demands” Statement made in code to protect access to a resource Checks all callers for the required permission May be “Imperative” or “Declarative” Declarative Specified via Custom Attributes before a Class, Method, etc … Imperative Initiated by Calling Demand() on a Permission instance Checks Enforced through Stack Walk Failed Demands raise a SecurityException

Declarative Demands Specified using Custom Attributes Stored in the assembly’s metadata Permission State must be known at compile time Can be viewed with PermView SDK Tool [FileIOPermission(SecurityAction.Demand, Write = "c:\\temp")] public void foo() { // class does something with c:\temp }

Declarative Demands Link and Inheritance Demands Checks only immediate caller for required permission Used to seal access to a method or restrict derivation Link Demand: “My caller must be signed with Key xxx” Inheritance Demand: “ You may only subclass me if you’re signed with Key yyy” Checks only the first call to a protected member Occurs during JIT Compilation Performs better than a full Demand

Imperative Demands Allows Security Checks to Vary by Control Flow or Method State Initiated with call to Demand() Example: A File Constructor public File(String fileName) { //Fully qualify the path for the security check String fullPath = Directory.GetFullPathInternal(fileName); new FileIOPermission(FileIOPermissionAccess.Read, fullPath).Demand(); //The above call will either pass or throw a //SecurityException //[…rest of function…] }

Putting it all Together PolicyEvaluator Assembly A3 SecurityPolicy Evidence G3 Host GrantedPermissions Assembly A1 Assembly A2 Assembly A3 G2 G1 G3 Call Stack

Stack-walking Semantics Method M3 Method M2 Method M1 Method M4 Call Stack Grows Down G2 G1 G3 G4 Each method has a set of corresponding grants Method M4 demands a permission P P P is compared with grants of all callers on the stack above M4 P P P

Stack Walk Modifiers Modifiers allow fine-grained control of the stack walk Assert, Deny, PermitOnly Most common modifier is Assert “I vouch for my callers; checks for this permission can stop with me” Use with Caution!! Example: “Gatekeeper” classes Managed wrappers for unmanaged resources Demand appropriate permission from caller Assert permission to call unmanaged code Make the unmanaged call

Key Takeaways CAS is based on code identity Augments Windows Security Model Administrators Set Security Policy Evidence Granted Permissions.Net Configuration Tool Code Authors Demand Permissions Protects access to resources CLR uses the call stack to enforce policy

Additional Resources “.NET Framework Security”, Addison- Wesley MSDN Security Site DEV340 “.Net Framework Security Best Practices”

Community Resources MS Community Sites List of newsgroups microsoft.public.dotnet.general microsoft.public.dotnet.framework microsoft.public.dotnet.clr microsoft.public.dotnet.security ListServs ADVANCED-DOTNET DOTNET-CLR DOTNET-ROTOR Attend a free chat or webcast Locate a local user groups Community sites

evaluations evaluations

© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.