MSDN Magazine - April 2008 - (Page 47)

Code Access Security in WCF, Part 1 JUVAL LOWY I ntroduced in the Microsoft® .NET Framework 1.0, code access security (CAS) is probably the single differentiating capability of .NET compared with unmanaged code. CAS is built into the very fabric of the .NET Framework, affecting every operation in managed code, something that unmanaged code can never achieve. The first release of Windows® Communication Foundation (WCF) offered no support for CAS; the System.ServiceModel assembly did not allow any partially trusted callers, which disabled CAS support. The second release introduced rudimentary support for CAS in some of the HTTP bindings and only for a limited set of scenarios. This change enabled me to write a small framework that provides comprehensive support for CAS without compromising either the WCF programming model or CAS. In this first installment of two columns on CAS, I will briefly discuss code access security in WCF, and then proceed to show my solution for enabling partially trusted clients of WCF services. CAS at a Glance The .NET Framework defines 24 different security permissions, governing almost any type of operation. There are permissions for file I/O, UI, reflection, security, network, data access, and so on. A permission type can be applied to a specific resource, such as permission to read from a specific file in the case of the file I/O permission or permission to display specific types of windows as with the UI permission. It may also be completely denied (such as no file I/O operations at all) or completely granted (such as unrestricted file I/O access). Permissions are grouped into permission sets and every assembly is assigned a set. The .NET Framework defines some standard permission sets such as FullTrust (implies all permissions) or Execution (permission to only access the CPU). Administrators can use the .NET Configuration tool to define custom permission sets, and developers can define custom permission sets programmatically—or use a permission set file, or define a ClickOnce application manifest with the permission set required by their application. The CLR assigns each assembly its permissions when the assembly is loaded. Assemblies are granted these permissions based on some form of evidence substantiating their identity. There are originbased evidences that examine where the assembly is loaded from (for example, all code coming from the Global Assembly Cache, or GAC, is granted full trust), or content-based evidence that examines some aspect of the assembly itself, such as its strong name. Each app domain is always assigned a permission set called the app domain security policy, and any assembly loaded into that app domain is restricted to that permission set; otherwise it encounters a security exception. New app domains are launched with the FullTrust permission set, and since all code originating from the local machine also gets FullTrust by default, most .NET-based applications just work out of the box, in effect not utilizing CAS at all. This renders the code (and the user, the data, the machine, The .NET Framework and even the network) susdefines 24 different security ceptible to a variety of malpermissions, governing adies, from security attacks such as viruses or worms, to almost any type of operation. plain user mistakes. Permissions are grouped Code that is executing into permission sets and with less than full trust every assembly is assigned a is called partially trusted permission set. code. Whenever any piece of managed code tries to access a resource or perform any operation using the .NET Framework (including interoperability with unmanaged code), the .NET Framework verifies that the assembly containing that code has the required permissions to perform the operation. If that assembly lacks a demanded permission, the .NET Framework throws a security exception thus aborting the operation. Since a trusted assembly can be lured by a malicious, less-trusted assembly into performing operations that the less-trusted assemblies does not have permissions to execute, it is insufficient to demand the permissions only of the assembly performing an operation. Therefore, the .NET Framework walks the entire stack of callers, verifying that every caller up the stack has the required permissions. This stack walk is called a security demand, and it is performed regardless of the executing assembly’s permissions. Your code can also assert a permission—that is, declare that every caller up the stack has the demanded permissions. A permission assertion has the effect of stopping a stack walk. Your code can only assert permissions it already has, and it additionally requires the special security assertion permission. It is always a good idea when asserting one permission to demand another in its place. Developers can demand or assert permissions programmatically using dedicated permission classes or use a matching set of attributes. Developers can also actively refuse april2008 47

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.