Customizing .NET Security – Evidence and Code Identity..

Customizing .NET Security – Evidence and Code Identity.. By, Srikanth Poluru. 00559151. Course: CS795-31107.

Topics Covered • .NET Security • Introduction to Code Access Security. • Evidence:- • Introduction • Assembly Provided Evidence :- • Write the custom evidence using the binaryFormatter into a file • Compile your assembly into a netmodule • Use the AL.exe tool to link the evidence into the assembly • Enumerating Evidence • Code Identity:- • Introduction • Implementation

.NET security • .NET Code Access Security is based on assemblies and evidence. Permissions are applied to entire assemblies, and an assembly can specify the minimum permissions it requires through custom attributes (see .NET metadata). When the assembly is loaded the CLR will use the evidence for the assembly to create a permission set of one or more code access permissions. The CLR will then check to make sure that this permission set contains the required permissions specified by the assembly. • .NET code can perform a code access security demand. This means that the code will perform some privileged action only if all of the assemblies of all of the methods in the call stack have the specified permission. If one assembly does not have the permission a security exception is thrown. • The .Net code can also perform Linked Demand for getting the permission from the call stack. In this case the CLR will look for only one method in the call stack in the TOP position has the specified permission. Here the stack walk through is bound to one method in the call stack by which the CLR assumes that all the other methods in the CALL STACK have the specified permission.

Code Access Security • CAS, in the Microsoft .NET framework, is Microsoft's solution to prevent untrusted code from performing privileged actions. When the CLR loads an assembly it will obtain evidence for the assembly and use this to identify the code group that the assembly belongs to. A code group contains a permission set (one or more permissions). Code that performs a privileged action will perform a code access demand which will cause the CLR to walk up the call stack and examine the permission set granted to the assembly of each method in the call stack. If one of these assemblies is not granted the demanded permission then a security exception is thrown and execution stops. • The code groups and permission sets are determined by the administrator of the machine who defines the security policy. • In today’s environment, code does not reside on a static, predetermined location but instead is frequently originating from unknown remote sources and may move from location to location through email or is sent across a network to be downloaded on a remote system. Because the possibilities are endless, the code today can be termed as “mobile code” or “code in transition”. The .NET framework offers a mechanism called Code Access Security that assists us in protecting application systems from malicious code, granting trust levels to the code and allowing codes from unknown locations to run safely on the local system.

Evidence Whenever an assembly is loaded into the runtime, the hosting environment presents the security system with evidence for the assembly. Evidence constitutes the input to the code access security policy system that determines what permissions an assembly receives. Theoretically, any managed object can constitute evidence. The ones that are provided at runtime are just types that have corresponding membership conditions in the .NET Framework, and can thus be integrated into security policy without having to write custom security objects.

Evidence • A developer can use custom evidence (so-called assembly evidence) but this requires writing a security assembly and in version 1.1 of .NET this facility does not work. • Evidence based on a hash of the assembly is easily obtained in code. For example in C#, evidence may be obtained by the following code clause: this. GetType(). Assembly. Evidence • The following program is a simple example of the evidence passed to the runtime security system when an assembly is loaded. In this case, mscorlib is the loaded assembly; this is the assembly that contains many of the runtime types, such as Object and String.

Evidence. • using System;using System.Collections;using System.Reflection;using System.Security.Policy;namespace AssemblyEvidence{ class Class1 { static void Main (string[] args) { Type t = Type. GetType ("System.String“ ); Assembly a = Assembly. GetAssembly(t); Evidence e = a. Evidence; IEnumerator i = e. GetEnumerator(); while( i. MoveNext()) Console. WriteLine( i. Current); } }}

Evidence • The output from the program shows what evidence was passed to the security system for this assembly. The output below it has been edited for brevity. The security system takes this evidence and produces a permission set for the assembly based on security policy as set by the administrator. • <System.Security.Policy.Zone version="1"> <Zone>MyComputer</Zone></System.Security.Policy.Zone><System.Security.Policy.Url version="1"> <Url> file:///C:/winnt/microsoft.net/framework/v1.0.2728/mscorlib.dll </Url></System.Security.Policy.Url><StrongName version="1" Key="00000000000000000400000000000000" Name="mscorlib" Version="1.0.2411.0"/><System.Security.Policy.Hash version="1"> <RawData>4D5A90000300000004000000FFFF0000B8000000000000... 0000000000000000000000000000000000000000000000000000 </RawData></System.Security.Policy.Hash>

Evidence • A number of classes that ship with the .NET Framework are used as standard forms of evidence in the security system: • Zone: The same concept as zones used in Internet Explorer. • URL: A specific URL or file location that identifies a specific resource. • Hash: The hash value of an assembly generated with hash algorithms such as SHA1. • Strong Name: The strong name signature of an assembly. Strong names represent a versioned, cryptographically strong way to refer and identify an assembly or all assemblies of a particular signing party. For more information, please consult the .NET Framework SDK. • Site: The site from which the code came. A URL is more specific than the notion of a site; for example, www.microsoft.com is a site. • Application Directory: The directory from which the code is loaded. • Publisher certificate: The Authenticode digital signature of the assembly. • These evidences are given when the runtime loads the assembly.

Customizing .NET Security Using Evidence • We all know that the CLR provides many types of evidence to assemblies and AppDomains by default, but one feature of the runtime that's much less known is that assemblies can actually provide evidence of their own. This seems to be one of the best kept secrets in CLR security. (In a somewhat interesting note, nearly everybody on the security team knew that this was possible, but the number of people who actually knew how to embed the evidence was not nearly as high ). • Obviously evidence that's provided by an assembly is not as trustworthy as evidence that's provided by a host, however you can imagine situations in which assembly provided evidence could be used to make trust decisions for an assembly. One example might be an assembly that ships with a signed XML file indicating the results of a security audit done by a trusted company:

Customizing .NET Security <securityAudit> <assembly strongName="TrustedAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=173144ef9dd6c5fd"> <auditDate>2/20/2007 11:39:03PM</auditDate> <auditResult>success</auditResult> <verificationUrl> http://audits.trustedcompany.com/auditResult.aspx?auditId=12345 </verificationUrl> </assembly> <Signature xmns="http://www.w3.org/2000/09/xmldsig#">  <X509Data>  </X509Data>  </Signature> </securityAudit>

Customizing .NET Security • Since this hypothetical XML blob contains the strong name of the assembly to which it refers and the X.509 certificate of the company that did the audit and produced the signature, we could choose to trust that assembly if we trusted the company that provided the blob. • So, how would I go about embedding this custom evidence into my assembly? It's basically a three step process: • Write the custom evidence using the BinaryFormatter into a file • Compile your assembly into a netmodule • Use the AL.exe tool to link the evidence into the assembly • Lets look at each step in detail.

1. Write the custom evidence using the BinaryFormatter into a file The first step is to serialize the assembly evidence into a file that can be used by build tools to embed into the assembly. To do this, you'll need to write a short program that dumps the evidence out. The code looks something like this:

public static void Main() { XmlElement auditSignedXml = GetAuditSignedXml(); Evidence evidence = new Evidence(); evidence.AddAssembly(auditSignedXml.OuterXml); using (FileStream evidenceFile = new FileStream("TrustedAssembly.evidence", FileMode.Create, FileAccess.Write)) { BinaryFormatter formatter = new BinaryFormatter(); formatter.Serialize(evidenceFile, evidence); } return; }

This code is fairly straightforward. First we load up the XML that our security auditors gave us into an XmlElement. We can't add the XmlElement directly into the evidence however because all evidence must be serializable and XmlElement is not. However, String is, so we can just get the OuterXml and add it to the Assembly evidence collection. It's important to AddAssembly rather than AddHost here, otherwise the CLR will ignore the evidence when it loads your assembly. • Once the Evidence collection is created, we use a FileStream and the BinaryFormatter to dump the evidence to a binary file on disk, in this case cleverly named TrustedAssembly.evidence, however any name will do.

2. Compile your assembly into a netmodule The next step is to compile the code that would normally go into your assembly, however this time instead of building an .exe or .dll, you want to build a .netmodule. In C# this is done by saying /target:module on the command line, and VB supports a similar switch. Properties in the Visual Studio UI to produce a netmodule can be manually edited to your project file to achieve this:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup>  <OutputType>Module</OutputType>  </PropertyGroup>  </Project> • In a standard Visual Studio generated project, you'll just have to change the OutputType property to be a Module rather than an Exe or a Library. This will cause the build to output <projectname>.netmodule as its result.

3.Use the AL.exe tool to link the evidence and netmodule into an assembly • The final step is to use the AL.exe tool to link the binary evidence file and the .netmodule containing the code for your assembly into the final assembly. AL takes the input evidence using it's /evidence command line switch, so an example of linking TrustedAssemblyEvidence.bin with TrustedAssembly.netmodule to produce TrustedAssembly.exe would be: al.exe /evidence:TrustedAssembly.evidence /out:TrustedAssembly.exe /main:Microsoft.Samples.TrustedAssembly.Main /target:exe /keyfile:TrustedAssembly.snk TrustedAssembly.netmodule

Here we tell al to link our evidence and our netmodule into an exe named TrustedAssembly.exe, setting the entry point to be Microosft.TrustedAssembly.Main and signing the assembly with TrustedAssembly.snk. • That's it, the resulting assembly now has evidence embedded within it. If you load this assembly in the CLR, you can look at it's evidence and in addition to the standard evidence types you would find if you looked at the output of GetHostEnumerator, you would find the string containing this XML blob in the assembly enumerator. A custom CLR host could use this evidence to decide that although this assembly was loaded from the Internet, it trusts the company that did the security audit, and therefore will grant the assembly extra permission

Evidence Based Security • Evidence is information gathered about code or assemblies based on the questions raised by the security policy. once this information is accumulated, the security policy can grant permissions to a code. • Thus evidence can be anything known about the code such as digital signatures, the URL, the zone that the code is originating from and so forth. The CLR and the host of the application domain gather the evidence. • Three kinds of hosts are provided by default namely: • Microsoft Internet Explorer • ASP.NET • Shell Host (e.g.: CMD Console)

Once the host and the CLR have gathered all the evidence, it is submitted to the security policy as a set objects encapsulated in a single collection object of type Evidence. • Figure 1.0 shows how evidence is gathered: • A simple example of an evidence can be a URL for an ASP.NET application. • Evidence based security works in tandem with Windows logon security. If we attempt to run a .NET desktop application, it must be granted the relevant .NET code access security permissions. However we as the logged-in user must also be running under a Windows account that has the relevant permissions to execute the code. Most application code does

not need evidence based security explicitly since it is usually handled by the standard .NET libraries. One thing that an application can do to use evidence–based security is to include a permission request, this will ensure that the code will only run and that the code gets only those permissions it expects to have. Other situations that can make use of evidence based security are listed below: • Limited access public API: for instance, to make public API that only other code from our site can call or only the code signed with a certain key can use. • Resource protection: when we define a class library that exposes resources need protection we can define permissions and the security policy system can restrict access.

Code Identity : • There are only two ways for code to become executable: • through the class loader or • through interoperability services. • Both of these are services provided by the common language runtime and are part of the security perimeter. For example, the class loader maintains information about the source of every implementation that it loads. Therefore, the class loader is able to reliably provide some of the evidence upon which you can base code identity. Evidence can include information such as which Internet zone and site the code originated from, its shared name, and its publisher's identity. Using this information, security policy can control the privileges granted to a specific application or collection of related applications. • Code Access Security This mechanism provides policy-based enforcement over privileges granted to executing assemblies. These privileges can control access to

system resources and other code based on the notion of permissions. .NET provides a fairly broad set of permissions related to common resources and code evidence-based identity. Tools or application developers can extend these by adding new permission types to meet specific needs.Consider the case of an application that wants to read and write a file in C:\Temp. To open a file in this directory, a managed application would use the base framework's System.IO.File class. This class contains a static method called Open. Internally, the Open method takes the path name of the file that the caller wants to open, and asks the common language runtime engine if access to the specified path name is allowed. This is called demanding access. In this case, the Open method demands that the calling code be granted a FileIO permission with read and write access to C:\Temp\*.* before it will attempt to open the file.

When a method demands access, the common language runtime walks up the call stack and checks to see if all assemblies in the call chain have the required permission. If any code in the call chain lacks the required permission, then the demand fails and a security exception is thrown; otherwise, the demand succeeds. To complete the File.Open operation, the File class needs to call the OS file system APIs. This requires the new UnmanagedCode permission, which is typically granted to highly trusted resource-managing classes. The system will check that the File class has this permission before allowing the call to unmanaged code. You should note that the other semi-trusted assemblies in the call chain aren't expected to have been granted this permission. To allow the UnmanagedCode permission demand to succeed, highly trusted code is allowed to assert its right to use a permission. This causes the permission-check stack walk to terminate at the assembly that asserted the permission.

The .NET Framework provides a unique method of security that has nothing to do with users. The code access security model focuses on code identity instead of user identity. But to get the most out of this security method you have to master the .NET identity-based security mechanism. To learn more about these concepts read this tip excerpted from InformIT. • The .NET Framework includes a simple but very flexible identity-based security mechanism. By using it, you can exercise very fine-grained control over who is allowed to use your programs and which functions those users can perform. The key is a detailed understanding of the Principal and Identity objects. • The Microsoft .NET Framework provides a robust and flexible security infrastructure that can be split into two sections: code access security and identity-based security.

The code access security (CAS) model focuses on code identity instead of user identity. Using CAS, you set policies and permissions on assemblies according to their publisher or where they were loaded from, for example. The user identity of the hosting process is irrelevant in the permission granting logic. • Compared with CAS, identity-based security represents a classic approach with which most programmers are confident. However, you'll need to master some important concepts to get the most from the .NET Identity Based security infrastructure.

Conclusion This way the evidence and the code identity work in an efficient way in maintaining the security of the code and the personal data.

THANK YOU Questions ?

Customizing .NET Security – Evidence and Code Identity..