Using and Administering Security Policy

Before getting too deep into a discussion on how to use and administer the security policy, you should know what kinds of permissions can be granted and denied to your code and the code of other developers. Table 14.1 lists the various permission classes available within the .NET Framework. CAS is implemented in such a way that each permission is actually a class. You will see more about permission classes in the section on Imperative Security. Don't worry if you don't understand the purpose of each permission, as that will become clear when you work with the technology related to each permission, such as ASP.NET, networking, and so on.

Table 14.1. Code Access Permissions

Permission Class	Code Right or Privilege Granted
AspNetHostingPermission	Access to resources within ASP.NET applications.
DirectoryServicesPermission	Access information contained within Active Directory (System.DirectoryServices namespace).
DnsPermission	Ability to resolve host names using DNS.
EnvironmentPermission	Ability to read or write environment variables.
EventLogPermission	Ability to write entries to the system event log.
FileDialogPermission	Ability to access the file(s) indicated by a user in a File | Open dialog box.
FileIOPermission	Ability to read/write files or directories.
IsolatedStorageFilePermission	Ability to access Isolated Storage.
MessageQueuePermission	Ability to access MSMQ Queues.
OdbcPermission	Ability to access data sources via ODBC.
OleDbPermission	Ability to access data sources via OLE DB.
OraclePermission	Ability to access an Oracle database.
PerformanceCounterPermission	Ability to read/write system-level performance counters.
PrintingPermission	Ability to communicate with printers.
ReflectionPermission	Ability to obtain run-time type information via Reflection. Never give this permission to suspect or untrusted code.
RegistryPermission	Ability to access the system registry.
SecurityPermission	Ability to execute, assert permissions, call unmanaged code, and other security-related activities.
ServiceControllerPermission	Ability to start/stop/pause system services.
SocketPermission	Ability to communicate over the network using sockets.
SqlClientPermission	Ability to access SQL databases.
UIPermission	Ability to access user interface functionality, such as creating a Windows Form, and so on.
WebPermission	Ability to make or accept web connections.

In addition to the Code Access Security permissions shown in Table 14.1, there are also Identity Permissions and Role-Based Security Permissions. Identity permissions allow code to restrict the callers based on their identity rather than by permissions that have been explicitly granted. For example, you could choose to build an assembly that can only be invoked by other code that you have developed, or you can build an assembly that can only be invoked by code written by Microsoft.

Table 14.2 shows the list of Identity Permissions with which you can work.

Table 14.2. Identity Permissions

Permission	Identity Aspect
PublisherIdentityPermission	Refers to the publisher's digital signature.
SiteIdentityPermission	The site from which the code was downloaded.
StrongNameIdentityPermission	The strong-name identity of the assembly. A strong name consists of name, culture, version, and public key token.
URLIdentityPermission	The URL from which the code was downloaded.
ZoneIdentityPermission	The zone from which the code was downloaded.

One identity that is missing from the list in Table 14.2 is the identity of the user who is running the code. This is an extremely important aspect because the code needs to know the user who invoked it in order to determine if the user can access certain protected resources such as system files, files owned by other users, or even the network.

You can also write code that restricts the identity of the user who invoked the code based on that user's name or even his domain group/role membership using the PrincipalPermission class.

Code Access Security Administration

The .NET security policy is configured through the use of very specific XML files in certain locations. Although it might be useful for you to know the location and the format of these XML files, such information is beyond the scope of this chapter.

Instead, you can make use of some tools that ship with the .NET Framework that allow you to modify the security policy using a easy-to-use, friendly user interface.

The main tool for administering the .NET Framework security policy (as well as many other settings) can be found in your Administrative Tools control panel menu. It is called .NET Framework 2.0 Configuration. This application is displayed in Figure 14.2.

Figure 14.2. .NET Framework 2.0 configuration.

To administer the runtime security policy, click the Runtime Security Policy node. You will see the following task list in the right-hand content panel:

• Increase Assembly Trust Allows you to browse for a specific assembly and increase the trust level of either that specific assembly, or all assemblies with the same public key (all assemblies produced by the same company).

• Adjust Zone Security Modifies the security settings for each of the zones (Internet, Local Intranet, Trusted, My Computer, and so on).

• Evaluate Assembly Examines an assembly and displays that assembly's effective permission levels, including permissions inherited from enterprise-level policies.

• Create Deployment Package Takes an existing security policy level and places it in a Windows Installer (msi) package that can then be used to distribute the policy via Group Policy or Systems Management Server (SMS).

• Reset All Policy Levels Restores the security policy for the computer to the original settings created by the .NET Framework 2.0's installation. This will remove all changes made since the framework was installed.

You will make use of this administration tool when creating some of the sample applications shown in the following two sections of the chapter dealing with Imperative and Declarative security.