Chapter 11 Application Security Everyone has heard that you shouldn’t log on to your computer as an Administrator. The reason isn’t because you don’t trust yourself not to delete your hard drive; it’s because you don’t trust the applications you run. When you run an unmanaged appli­ cation in Microsoft Windows Server 2003, Microsoft Windows XP, and earlier ver­ sions of Windows, that code gets all the privileges your user account has. If you accidentally run a virus or a Trojan horse, the application can do anything your user account has permissions to do. So you are forced to log on with minimal privileges to restrict application permissions. Code access security (CAS), a concept that the .NET Framework introduced to Win­ dows, enables you to control the permissions that individual applications have. If a friend sends you a new .NET Framework text editor, you can restrict it to opening a window and prompting you to open and save files—and nothing else. The text edited wouldn’t be able to send e-mails, upload files to a Web site, or create files, even if you are logged on as an Administrator. CAS enables users to restrict on a very granular level what managed code can do. As a developer, you must understand how to create applications that work even when some permissions are restricted. You can also use CAS to improve your application’s security by restricting which callers can use your code and forcibly limiting your appli­ cation to a restricted permission set. Exam objectives in this chapter: ■ Implement code access security to improve the security of a.NET Framework application. (Refer System.Security namespace) ❑ SecurityManager class ❑ CodeAccessPermission class ❑ Modify the Code Access Security Policy at the computer, user, and enter­ prise level by using the Code Access Security Policy tool (Caspol.exe). ❑ PermissionSet class and NamedPermissionSet class ❑ Standard Security interfaces 627 628 Chapter 11 Application Security ■ Control permissions for resources by using the System.Security.Permission classes. (Refer System.Security.Permission namespace) ❑ SecurityPermission class ❑ PrincipalPermission class ❑ FileIOPermission class ❑ StrongNameIdentityPermission class ❑ UIPermission class ❑ UrlIdentityPermission class ❑ PublisherIdentityPermission class ❑ GacIdentityPermission class ❑ FileDialogPermission class ❑ DataProtectionPermission class ❑ EnvironmentPermission class ❑ IUnrestrictedPermission interface ❑ RegistryPermission class ❑ IsolatedStorageFilePermission class ❑ KeyContainerPermission class ❑ ReflectionPermission class ❑ StorePermission class ❑ SiteIdentityPermission class ❑ ZoneIdentityPermission class ■ Control code privileges by using System.Security.Policy classes. (Refer System.Security.Policy namespace) ❑ ApplicationSecurityInfo class and ApplicationSecurityManager class ❑ ApplicationTrust class and ApplicationTrustCollection class ❑ Evidence class and PermissionRequestEvidence class ❑ CodeGroup class, FileCodeGroup class, FirstMatchCodeGroup class, NetCode- Group class, and UnionCodeGroup class ❑ Condition classes Before You Begin 629 ❑ PolicyLevel class and PolicyStatement class ❑ IApplicationTrustManager interface, IMembershipCondition interface, and IIdentityPermissionFactory interface Lessons in this chapter: ■ Lesson 1: Understanding Code Access Security . 630 ■ Lesson 2: Using Declarative Security to Protect Assemblies. 658 ■ Lesson 3: Using Declarative and Imperative Security to Protect Methods. 672 Before You Begin To complete the lessons in this chapter, you should be familiar with Microsoft Visual Basic or C# and be comfortable with the following tasks: ■ Create a console application in Microsoft Visual Studio using Visual Basic or C#. ■ Add references to system class libraries to a project. ■ Write to files and streams. 630 Chapter 11 Application Security Lesson 1: Understanding Code Access Security If you have worked with previous versions of the .NET Framework, you might already be familiar with code access security (CAS) concepts. If you have been a Microsoft Windows developer but haven’t previously used the .NET Framework, using CAS requires you to understand completely novel security concepts. This lesson describes the concept behind CAS and each of the components that the .NET Framework uses to implement CAS. After this lesson, you will be able to: ■ Describe the purpose of CAS. ■ List the four most important elements of CAS and the significance of each. ■ Describe how security policy defines an assembly’s permission set. ■ Explain how CAS works with operating system security. ■ Use the .NET Framework Configuration tool to configure CAS. ■ Use Caspol to configure CAS. Estimated lesson time: 60 minutes What Is Code Access Security? Code access security (CAS) is a security system that allows administrators and develop­ ers to control application authorization similar to the way they have always been able to authorize users. With CAS, you can allow one application to read and write to the registry, while restricting access for a different application. You can control authoriza­ tion for most of the same resources you’ve always been able to restrict using the oper­ ating system’s role-based security (RBS), including the following: ■ The file system ■ The registry ■ Printers ■ The event logs You can also restrict resources that you can’t control using RBS. For example, you can control whether a particular application can send Web requests to the Internet or whether an application can make DNS requests. These are the types of requests that Lesson 1: Understanding Code Access Security 631 malicious applications are likely to make to abuse a user’s privacy, so it makes sense that CAS allows you to restrict those permissions. Unfortunately, CAS can be applied only to managed applications that use the .NET Framework runtime. Unmanaged applications run without any CAS restrictions and are limited only by the operating system’s RBS. If CAS is used to restrict the permis­ sions of an assembly, the assembly is considered partially trusted. Partially trusted assemblies must undergo CAS permission checks each time they access a protected resource. Some assemblies are exempt from CAS checks and are considered fully trusted. Fully trusted assemblies, like unmanaged code, can access any system resource that the user has permissions to access. Elements of Code Access Security Every security system needs a way to identify users and determine what a user can and can’t do, and CAS is no exception. However, because CAS identifies and assigns permissions to applications rather than to people, it can’t use the user names, pass­ words, and access control lists (ACLs) that you’re accustomed to. Instead, CAS identifies assemblies using evidence. Each piece of evidence is a way that an assembly can be identified, such as the location where the assembly is stored, a hash of the assembly’s code, or the assembly’s signature. An assembly’s evidence determines which code group it belongs to. Code groups, in turn, grant an assembly a permission set. The sections that follow describe each of these components in more detail. What Is Evidence? Evidence is the information that the runtime gathers about an assembly to determine which code groups the assembly belongs to. Common forms of evidence include the folder or Web site from which the assembly is running and digital signatures. NOTE Evidence: a misnomer Identification might be a better term than evidence. Evidence sounds like a set of clues you use to track down someone who didn’t want to be identified. In CAS, evidence is used just like a person’s passport, password, and PIN—information that proves identity and describes an individual as deserving a certain level of trust. Table 11-1 shows the common types of evidence that a host can present to the run­ time. Each row corresponds to a member class of the System.Security.Policy namespace. 632 Chapter 11 Application Security Table 11-1 Evidence Types Evidence Description Application directory The directory in which the assembly resides. Hash The cryptographic hash of the assembly, which uniquely identifies a specific version of an assembly. Any modifica­ tions to the assembly make the hash invalid. Publisher The assembly’s publisher’s digital signature, which uniquely identifies the software developer. Using Pub­ lisher evidence requires the assembly to be signed. Site The site from which the assembly was downloaded, such as www.microsoft.com. Strong Name The cryptographic strong name of the assembly, which uniquely identifies the assembly’s namespace. The assem­ bly must be signed to use Strong Name evidence. URL The URL from which the assembly was downloaded, such as www.microsoft.com/assembly.exe. Zone The zone in which the assembly is running, such as the Internet zone or the LocalIntranet zone. There are two types of evidence: host evidence and assembly evidence. Host evidence describes the assembly’s origin, such as the application directory, URL, or site. Host evidence can also describe the assembly’s identity, such as the hash, publisher, or strong name. Assembly evidence is custom user- or developer-provided evidence. What Is a Permission? A permission is a CAS access control entry. For example, the File Dialog permission determines whether an assembly can prompt the user with the Open dialog box, the Save dialog box, both, or neither. Figure 11-1 shows the File Dialog permission being configured. By default, 19 permissions are available for configuration in the .NET Framework Configuration tool. Each corresponds