Security for Developers Code Access Security Steven Borg & Richard Hundhausen Accentient, Inc

Overview Overview of Code-Access Security Code Access Permissions Imperative vs. Declarative Security Operations Adding Permission Requests

Overview of Code-Access Security The Basics Evidence Security Policy Code Groups Security Policy Levels How Policy Levels Resolve Permission Grant Why Modify Security Policy?

.NET Security Basics Evidence Inputs to policy about code Strong name, site, zone, Authenticode signature Permissions Specific authorizations Define a level of access to a resource Policy Determines what code can do Grants permissions to an assembly

What Is Evidence? Data about an assembly the assembly loader uses to determine whether to load an assembly Code location (URL) Zone of origin Simple name Authenticode signature Cryptographic hash Strong name Forms of evidence WeakerStronger Relative strength

Evidence The CLR examines evidence about code to determine which permissions to grant Evidence is presented by an assembly at load time: From what site was this assembly obtained? From what URL was this assembly obtained? From what Zone was this assembly obtained? Whats the strong name of this assembly? Who signed this assembly?

Evidence = input to policy Example: Info about a code assembly Strong names Publisher identity Hash Location of origin (URL, IE zone, site) Evidence is completely extensible Any object can be a piece of evidence Time of day, 3 rd party certification, etc. Only impacts grants if there is a code group membership condition that tests for it Assemblies may contain untrusted evidence cryptographically computed/validated }

Policy Evaluation in the CLR Policy is the process of determining the set of permissions to grant to code based on evidence known about that code Classic trust management problem Requiring end users to write programs to express policies is not possible CAS gives us an extensible model that can be easily administered.

What Is a Security Policy? A security policy uses evidence to control the permission set that an application receives A security policy matches a specific type of evidence to a permission set Permission sets: NothingExecutionInternetLocalIntranetEverythingFullTrustCustom-defined

Evidence Based Security Code Groups Assembly evidence is matched against a code group to gain permissions A code group has 2 attributes Membership condition Permission set An assembly can match more than one code group

Evidence Based Security Membership Conditions A code group may have only one membership condition It is comprised of an attribute that matches evidence presented by an assembly Zone of originating assembly URL of originating assembly Digital signature of assembly publisher Web site of the originating assembly

What Is a Code Group? Code groups Permission Grant Evidence ContosoApp.dll Publisher = Contoso SNKey = 9F AD… Read C:\Contoso Read C:\ContosoApp\Temp Write: C:\Contoso Adatum.exe Publisher = Adatum SN Key=25 98… Execute Read:C:\Adatum Definition: A code group matches evidence to a permission set. Site = Adatum.com All Printer Access Site = Adatum.com All Printer Access Publisher=Contoso Read:C:\Contoso Publisher=Contoso Read:C:\Contoso Zone=Internet Internet Zone=Internet Internet Zone=MyComputer Execute Zone=MyComputer Execute SN Key=25 98… Read:C:\Adatum SN Key=25 98… Read:C:\Adatum SN Key = 9F AD… Simple Name = ContosoApp Read:C:\..ContosoApp\Temp SN Key = 9F AD… Simple Name = ContosoApp Read:C:\..ContosoApp\Temp SN Key = 1A GG… Simple Name = Northwind Write:C:\Northwind SN Key = 1A GG… Simple Name = Northwind Write:C:\Northwind All Code Nothing All Code Nothing

Security Policy Level Four levels of policy in.NET EnterpriseMachineUser Application Domain Each level contains code groups that map assemblies to permissions Policy evaluation is from Enterprise down to Application Domain

Resolving Permission Grant Final permission is based on the intersection of permission sets granted at each policy level Code Groups Membership Condition Permission Set Code group A(root group) All code Nothing Code group B Publisher is Contoso.com Read access to files in C:\Contoso Code group C Site is *.contoso.com Read access to USERNAME environment variable Code group D Strong-name key is 45 9A EF Read access to files in C:\TEMP Publisher is Contoso.com Strong-name key is 45 9A EF Read access to files in C:\Contoso Read access to files in C:\TEMP

Why Modify Security Policy? Developers and testers: To verify application functionality under a range of security policy scenarios To test application security Systems administrators: To apply security best practices To facilitate application deployment

Administration Tools The.Net Framework configuration tool can be used to modify and manage security policy Mscorcfg.msc - Management Console The command-line tool caspol.exe can be used to modify and managed security policy

Security Policy Administration The.Net Framework configuration tool can be used to modify and manage security policy Tool update XML files

Security Policy Administration Machine Policy Code Groups Each group defines a set of permissions granted when an evidence match is madeEach group defines a set of permissions granted when an evidence match is made Five code groups in default.NET Machine PolicyFive code groups in default.NET Machine Policy

Security Policy Administration Permission sets Sets of permissions referred to by the code groupsSets of permissions referred to by the code groups

Using the Code-Access Security Policy Tool Open the Visual Studio.NET command prompt 1 1 Type a command indicating the policy level and what you want to see 3 3 Run Caspol.exe 2 2 Caspol policy_level what_to_show SwitchDescription-l List the code groups and permission sets -lg Display code groups -lp Display the permission sets SwitchDescription-a All policy levels -enEnterprise -mMachine -uUser

Policy Configuration Tools

Code Access Permissions Permissions represent access to a protected resource or the ability to perform a protected operation They are fundamental to CLRs ability to enforce security restrictions on managed code

Restricted Resources Directory Services DNSEnvironment Event Log File Dialog File I/O Isolated Storage Message Queue OLE DB PrintingReflectionSecuritySocketUIWeb

CodeAccessPermission Class All code access permissions derive from CodeAccessPermission CodeAccessPermission defines the underlying structure of all code access permissions Code access permissions use a stack walk to ensure that all callers of the code have been granted a permission

SecurityException SecurityException forms the basis of all security violations committed by code running in the CLR If the system denies a request, it does so by throwing an exception of type SecurityException SecurityExceptions represent a virtual slap-on-the-wrist; Dont do that…

Code Access Permissions Code access permissions support the following methods: AssertDemandDenyPermitOnlyRevertAllRevertAssertRevertDenyRevertPermitOnly

Assert Calling Assert prevents a stack walk originating lower in the call stack from proceeding up the call stack beyond the code that calls this method Disables the stack walk for the frame ALWAYS VERIFY YOUR ASSERTS!

Security system Grant access? Call stack Call to NUMBER_Of_PROCESSORS SomeAssembly Grant: Execute.NET Framework Assembly Grant: read the system variable: NUMBER_OF_PROCESSORS Call to NUMBER_Of_PROCESSORS FinanceCalculator Assert: Read system variable: NUMBER_OF_PROCESSORS Permission Asserts The Assert method reduces the reach of the permission demand Use it to couple a.NET Framework application to unmanaged code Caution: Using an Assert can create a security vulnerability The Assert method reduces the reach of the permission demand Use it to couple a.NET Framework application to unmanaged code Caution: Using an Assert can create a security vulnerability Permission Demand

Demand Forces a SecurityException at run time if all callers higher in the call stack have not been granted the permission specified by the current instance Can be used to test for available permissions

Permission Demands YourAssembly (Execute + WriteFile) YourAssembly (Execute + WriteFile) SomeAssembly (Execute only) SomeAssembly (Execute only). NET Framework Assembly (Execute + WriteFile). NET Framework Assembly (Execute + WriteFile) WriteFile 1. An assembly requests Write access via your assembly 2. Your assembly passes Write request to a.NET Framework assembly 3. Security system issues a permission demand up the stack 4. Security system either grants access or throws an exception 1. An assembly requests Write access via your assembly 2. Your assembly passes Write request to a.NET Framework assembly 3. Security system issues a permission demand up the stack 4. Security system either grants access or throws an exception Permission demand Security exception Access denied Grant access? The Call Stack Security system

Deny Prevents callers higher in the call stack from accessing a resource specified by the current instance Pseudo-sandboxing

PermitOnly Prevents callers higher in the call stack from using the code that calls this method to access all resources except for the resource specified by the current instance Similar to Deny in that both cause stack walks to fail when they would otherwise succeed However, PermitOnly specifies permissions that do not cause the stack walk to fail

RevertAll Causes all previous overrides for the current frame to be removed and no longer in effect Rolls back all overrides made for the current frame

RevertAssert, RevertDeny, and RevertPermitOnly Each of these methods causes any previous Assert/Deny/PermitOnly for the current frame to be removed and no longer in effect

Other Security Checks To perform this operation: Use this method: Compare two permissions of the same class IsSubsetOf IsSubsetOf Combine and intersect permissions UnionIntersect

Imperative vs. Declarative Demands Imperative FileIOPermission p = new FileIOPermission( FileIOPermissionAccess.Write, f); p.Demand();Declarative [FileIOPermission(SecurityAction.Demand, Read = c:\\temp)] public void foo() { // class does something with c:\temp // class does something with c:\temp}

Imperative Demands Allows security checks to vary by control flow or method state Initiated with call to Demand() 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…] }

Declarative Demands Specified using Custom Attributes Stored in the assemblys 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 }

Demanding a Permission Imperatively To demand a permission imperatively: Create a new instance of a permission object 1 1 Call the objects Demand method in a try block 3 3 Set the properties on the permission object 2 2

Asserting a Permission Imperatively To assert a permission imperatively: Create an instance of a permission object 1 1 Call the Assert method on it 2 2

Using Declarative Permissions Use attributes to set permissions declaratively: AssertDemandDenyPermit

Identity Permissions Identity permissions are associated with the evidence for the assembly Identity permissions allow checking of: Publisher Strong name SiteURLZone

Link Demands A link demand specifies the set of permissions that direct callers must have to call your code A link demand is checked during JIT compilation of the caller A security exception results if the caller lacks sufficient permission Especially useful is a link demand that requires identity permissions Allows you to create a private assembly that can only be called by assemblies with the same publisher

Inheritance Demands An inheritance demand may be placed on a class or a method Level An inheritance demand requires that code have a specified permission to Class Inherit from the class Method Override the method

Permission Requests A permission request specifies those permissions an assembly requires to run, can run, and should not run Minimum permissions (RequestMinimum) The minimum set of permissions that the code needs to run Optional permissions (RequestOptional) Permissions that code can use but can run effectively without Refused permissions (RequestRefused) Permissions that code should never be granted The.NET Framework processes assembly permission requests at load time

Adding a Permission Request To request multiple permissions on the same assembly To request a named permission set [assembly:PermissionSet (SecurityAction.RequestMinimum,Name = "FullTrust")] [assembly:SecurityPermission (SecurityAction.RequestMinimum,UnmanagedCode = True)]

Best Practices Sandboxing code Rely on Security Policies Assert appropriately Strong Name your assemblies

Sandboxing Code Do not use Deny to sandbox code security Because the hacker can use Assert to bypass your limitation Rely on security policies Enterprise, machine-level and user policies Dynamically with AppDomains AppDomain.CreateDomainmyDomain.SetAppDomainPolicymyDomain.Load(<assembly>)myDomain.CreateInstanceAndUnwrap

Potentially Dangerous Permissions SecurityPermission UnmanagedCode – allows managed code to call into unmanaged SkipVerification – without verification, code can do anything. ControlEvidence – allows security policy to be fooled. ControlPolicy – can disable security or change policy ControlAppDomain – can change probing paths, load anything SerializationFormatter –can circumvent accessibility ControlPrincipal –can trick role-based security. ControlThread –security state associated with threads.

Potentially Dangerous Permissions ReflectionPermission MemberAccess – defeats accessibility mechanisms (can use private members). FileIOPermissionRegistryPermission

When to Assert? Clearly, the ability to assert permissions can be abused Unfortunately, the issue regards assertions is a bit cloudy Unmanaged code requires assertions Gatekeeper classes Rule: Demand before Assert Rule: Always code review your assertions!

Resources Steves Blog: Richs Blog: Security Book / Wiki:

Your Feedback is Important! Please Fill Out a Survey for This Session on CommNet

© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.