Using Code Access Security

The zero-installation based application delivery model introduced in .NET is very useful for developing and deploying rich client applications. However, with any notion of a downloadable code comes the requirement of security; otherwise , malicious code could be downloaded and executed and pose a high security risk to the client application. In some scenarios, this is the case when ActiveX controls-based applications are downloaded in the browser. To a certain extent, the problem is partially resolved by signing the ActiveX controls using Authenticode technology. However, a more proactive approach, in some sense similar to the Java Security model, is required to better support the security requirements of downloaded code.

A key highlight of the .NET application programming model is the introduction of Code Access Security (CAS), a brand-new mechanism introduced in the .NET Framework. CAS is targeted to handle the additional security requirements introduced by downloadable code. In a nutshell , CAS provides the .NET Framework runtime the capability to associate a set of permissions to code based on the identity of the code, or its evidence.

WHAT IS EVIDENCE?

The identity of the code, known as evidence, is based on a number of different elements: the site from where the application (or any .NET assembly) was downloaded, its URL, the Web content zone (Internet, local intranet, trusted sites, restricted sites, local machine), and the strong name of the assembly and/or a digital signature.

After the evidence related to a code has been collected, it is evaluated against a configurable security policy and based on the set of permissions available against the evidence; the code is granted or denied permission to perform a set of protected functions, as specified by the various permissions. See Table 14.1 for a list of these permissions.

Table 14.1. List of Permissions That Can Be Granted As Part of a Permission Set

PERMISSION	PROTECTED RESOURCES ENCAPSULATED BY THE PERMISSION
Directory Services	Directory service paths
DNS	Internet name resolution service
EventLog	Event logs
Environment Variables	Environment variables
File Dialog	Open/Save file dialog box
Isolated Storage File	File-based isolated storage
Message Queue	Message queues
OLE DB	OLE DB providers
Performance Counter	Performance counters
Printing	Printers
Registry	Registry keys
Reflection	Information about assemblies
Security	Assembly execution, calls to unmanaged assemblies, asset granted permissions, thread control, policy control, serialization formatter, remoting configuration, and so on
Service Controller	System services
Socket Access	Accept/connect sockets (TCP/UDP) communications
SQL Client	Microsoft SQL Servers
Web Access	Web sites
User Interface	User interface elements (top-level windows , subwindows, clipboard, and so on)

To understand the whole model, examine the previous HelloApp application, which is downloaded from a local intranet zone and attempts to write to a local file. By default, the permissions available to assemblies originating from the Local Intranet Zone have access to read certain environment variables, show File dialogs, utilize Isolated Storage File mechanisms (as highlighted in Chapter 4, "Using the .NET Class Library"), use DNS, and use printing services. You can confirm this through the .NET Framework 1.1 Configuration tool that is installed with the .NET Framework installation. However, as you can see, the Local Intranet Zone doesn't have the capability to write to the C:\HelloApp.txt file. If you would like to enable this permission for the application, you can create a custom policy that assemblies downloaded from the URL http://localhost/SmartApps/HelloApp.exe should have the custom File IO Permission to write into the C:\HelloApp.txt file. After you have set this permission in the .NET Framework 1.1 Configuration utility, if you run the application again, you should be able to run it without any problems.

AUTOMATIC AUTHENTICATION FOR INTRANET APPLICATIONS

The Local Intranet Zone can be used to configure automatic authentication for intranet applications. For instance, suppose you have a Web-based employee self-service application and that you use Active Directory for authentication. By adding the site's URL to the sites in the Local Intranet Zone, you can easily pass your Windows credentials to the site, effectively enabling single sign-on for your intranet site. This is typically required for intranet sites accessed by the FQDN (fully qualified domain name).

Apart from the GUI .NET Framework 1.1 Configuration tool (see Figure 14.2), security permissions can also be changed or viewed by the command-line “based Code Access Security Policy tool ( caspol .exe).

Figure 14.2. .NET Framework 1.1 Configuration tool.

In a number of scenarios, you will end up developing applications that will be deployed with different security policies based on the administrator and the corporate security guidelines. In such scenarios, to prevent raw Security Permission errors to be shown to the user, you might want to indicate to the execution environment that this particular part of the application requires such and such permissions by demanding them. And if the call to these demands fails, you can take an alternative route if possible.

For instance, you could modify the Write button event handler to demand the File IO Permission to write into the appropriate file before attempting to do so. In this scenario (Listing 14.3), you are merely appending the text of the exception message into the text box, but in an actual scenario you might want to pop up a message box (or show a status bar) containing a more user-understandable error message.

Listing 14.3 Demanding Permissions

 using System; using System.IO; using System.Windows.Forms; using System.Security; using System.Security.Permissions; namespace HelloApp {    public class HelloApp : Form    {       ...       private void WriteToFileButton_Click(object sender, System.EventArgs e)       {          String filename = "c:\HelloApp.txt";          String text = MsgBox.Text;  try {   new FileIOPermission(   FileIOPermissionAccess.Write,filename).Demand();  StreamWriter sw = new StreamWriter(filename);             sw.WriteLine(text);             sw.Close();  } catch (Exception ex) {   MsgBox.Text+=ex.Message;   }  }    } }