Windows 7 : Developing Applications with Enhanced Security - CONSIDERING MODERN APPLICATION SECURITY REQUIREMENTS (part 2) - Adding Permissions

5. Adding Permissions

The permissions granted or denied by NT security present one level of security; the permissions provided by the classes in the System.Security.Permissions namespace present a second level of security. This second level provides fine-grained control over specific kinds of tasks, rather than the coarse general control provided by NT security. For example, the FileDialogPermission class controls how a user can interact with a file dialog box — a fine level of control not provided by NT security.

In many cases, you have a choice between imperative or declarative security in implementing permissions. For example, the FileDialogPermission class provides a means of controlling file dialogs using imperative security, while the FileDialogPermissionAttribute class provides the same level of control using declarative security. The choice between imperative security and declarative security is a matter of personal choice and level of desired control. Declarative security, which relies on attributes, generally affects an entire assembly, class, or method, while imperative security works at the code level. You use imperative security when you need the utmost control of the permissions and don't mind writing a little more code to get it.

Many developers have gotten used to setting policies using CAS. Unfortunately, Microsoft has removed this capability in the .NET Framework 4. Consequently, methods you've used in the past, such as FileIOPermission.Deny(), no longer work without adding the <NetFx40_LegacySecurityPolicy enabled="true"/> tag to your application . You can see the <NetFx40_LegacySecurityPolicy enabled="true"/> tag documentation at http://msdn.microsoft.com/library/dd409253.aspx. The change makes sense. Virus code could simply use FileIOPermission.Assert() to override any denied privilege created by a lower level. You can read about this update at http://msdn.microsoft.com/library/ee191568.aspx.

You should understand that setting permissions is still important, and that you may need to use the outdated methods, such as FileIOPermission.Deny(), on some occasions. The CAS Policy example described in the following sections demonstrates a few important permissions features. First, you'll see how to use both declarative and imperative security. Second, the example demonstrates the dangerous nature of using these older permissions in some environments.

NOTE

One way to reduce the risk of using permissions to set policy is to sign your executable. Signing the executable makes it tough for someone to modify your code without the Common Language Runtime (CLR) detecting the change. This means that denying a permission will actually deny it as intended as long as your code is defined correctly.

5.1. Configuring the CAS Policy Example

The CAS Policy example begins with a Windows Forms application. You add a single button called Test (btnTest). In addition, you must add the following using statements to the application:

using System.IO;
using System.Security;
using System.Security.Permissions;

5.2. Creating a Legacy Security Configuration

Because this application is using outdated Deny() methods, you must also add a configuration file to the application that allows the use of legacy security. The following steps describe how to perform this task:

1. Right-click the project entry in Solution Explorer and choose Add => New Item from the Context menu. You'll see the Add New Item dialog box shown in Figure 2.

   Figure 2. Add a configuration file to your application.

   

2. Highlight the Application Configuration File template.

3. Type CAS Policy.EXE.CONFIG in the Name field and click Add. Visual Studio adds the configuration file to your application and opens it for editing.

4. Type the following code within the <configuration> element:

   <runtime>
       <NetFx40_LegacySecurityPolicy enabled="true"/>
   </runtime>

   
   

5. Highlight the configuration file in Solution Explorer.

6. Choose Copy if Newer in the Copy to Output Directory property in the Properties window.

5.3. Creating the CAS Policy Example Code

As previously mentioned, imperative security buries the security checks within the code, which means that you can perform the checks as needed. Listing 1 shows an example of imperative security.

Example 1. Using imperative security to control file access

// Use declarative security to restrict access to the // test file. [FileIOPermission(SecurityAction.Deny, AllLocalFiles=FileIOPermissionAccess.Read)] private void btnTest_Click(object sender, EventArgs e) { // Call the initial method for opening the file. UseSecurity(); // Call the override method to try again. OverrideSecurity(); } private void UseSecurity() { Stream FS = null; // A test file stream. // Try to access the object. try { FS = new FileStream( Application.StartupPath + @"\Temp.txt", FileMode.Open, FileAccess.Read); } catch (SecurityException SE) { // Display an error message if unsuccessful. MessageBox.Show("Access Denied\r\n" + SE.Message, "File IO Error", MessageBoxButtons.OK, MessageBoxIcon.Error); return; } // Display a success message. MessageBox.Show("File is open!", "File IO Success", MessageBoxButtons.OK, MessageBoxIcon.Information); // Close the file if opened. FS.Close(); } // This method uses imperative security to override the // previous permission denial. private void OverrideSecurity() { FileIOPermission FIOP; // Permission object. Stream FS = null; // A test file stream. // Create the permission object. FIOP = new FileIOPermission( FileIOPermissionAccess.Read, Application.StartupPath + @"\Temp.txt"); // Allow access to the resource. FIOP.Assert(); // Try to access the object. try { FS = new FileStream( Application.StartupPath + @"\Temp.txt", FileMode.Open, FileAccess.Read); } catch (SecurityException SE) { // Display an error message if unsuccessful. MessageBox.Show("Access Denied\r\n" + SE.Message, "File IO Error", MessageBoxButtons.OK, MessageBoxIcon.Error); return; } // Display a success message. MessageBox.Show("File is open!", "File IO Success", MessageBoxButtons.OK, MessageBoxIcon.Information); // Close the file if opened. FS.Close(); }

The example begins with a declarative permission attribute, FileIOPermission. In this case, the SecurityAction.Deny value denies a permission, AllLocalFiles defines it as pertaining to all local files, and FileIOPermissionAccess.Read specifies that the read permission is denied. This declarative permission applies to the btnTest_Click() method and every method that btnTest_Click() calls.

Figure 3. The declarative permission denies access to Temp.TXT.

To test out the permission, btnTest_Click() calls UseSecurity(). The UseSecurity() method creates a Stream object, FS, that it uses to open Temp.TXT for read access. Given that this action is denied, the open should fail. In this case, you do see the error message shown in Figure 3.

At this point, btnTest_Click() calls OverrideSecurity(). However, this time the code begins by creating a FileIOPermission object, FIOP. This object is designed to request the FileIOPermissionAccess.Read permission for Temp.TXT. It demonstrates the imperative approach for setting permissions (as contrasted to the declarative approach used earlier in this section). When the code calls FIOP.Assert(), the system grants access to the file. The code then uses precisely the same technique as in the UseSecurity() method to create a Stream object, FS. In this case, the call is successful, so you see the success message. After the user clicks OK, the code simply closes the file by calling FS.Close().

The point of this exercise is that permissions set using the classes in the System.Security.Permissions namespace are fluid. Code can easily change them as needed, which is why Microsoft is apparently abandoning at least the policy part of CAS. Still, this example shows how to implement the old-style code should you need it.

NOTE

This approach does come with some limitations, so you need to use it carefully. Native code images produced with the NGen utility can run slower. The basic reason for the performance loss is that the code marked with the <NetFx40_LegacySecurityPolicy> element must run as a Just-in-Time (JIT, pronounced "jit") assembly, rather than a native code image. In short, the CLR must compile the code every time before it can run it.