Defining Effective Declarative Security

Declarative security defines application security requirements as part of the declaration of main application elements such as a namespace, class, or method. It relies on attributes defined as part of an application element declaration, such as a method. The compiler normally processes these attributes during compile time, which means the declaration appears as part of the application manifest.

You’ve already seen several examples of declarative security throughout the book (and will see several more before the completion of the book). For example, the “Using the Permission View Tool” section of the chapter relies on declarative security. This example points out one of the reasons you should use declarative security in some cases. Declarative security creates entries in the assembly metadata that are easy to retrieve and use as a basis for setting assembly security. Someone who knows what an assembly requires in the way of security is less likely to make setup mistakes.

Declarative security is also good from a documentation standpoint. All of the security requirements for a particular element appear as part of the declaration. You don’t have to wade through the code to find the security statement that could cause coding problems down the road.

You can use declarative and imperative security interchangeably for many needs, but declarative security is more effective in some situations. Whenever you need to consider the documentation aspects of an application as a higher priority than ease of use or dynamic data manipulation, declarative security is the tool of choice.

Defining Effective Imperative Security

Imperative security appears as statements within the application code. You define a security object, and then use methods provided by that object to grant or deny access to various resources. CLR processes these statements at runtime. Consequently, imperative security doesn’t appear as part of the application manifest. The example in the “Executing Code in the Managed Environment” section of Chapter 1 shows just one way to use imperative security in an application.

Declarative security is important because it provides so many good features, such as instant documentation and good metadata access. In fact, declarative security may provide so many good features that you might be tempted to use it exclusively. However, you do need to use imperative security in some situations.

Whenever a security need requires a dynamic data path or other resource information, you must use imperative security. Because the compiler processes declarative security attributes during the compilation stage, you can’t change it at runtime. Using imperative security is the only way around this problem.

Many developers also find that imperative security is inherently easier to use because it appears as statements. Using declarative security means placing all security requirements at the very beginning of a module, which breaks up the code flow and means moving back and forth to really understand what the code means. In addition, attribute coding is relatively new. Most developers who learned to code before .NET arrived on the scene will find using statements more intuitive because they’ve always used statements in the past.

Securing the Registry

The registry is the central storage area for all kinds of information for the local machine, the user , and applications. Consequently, keeping the registry secure is an important issue. Fortunately, the .NET Framework makes working with the registry a lot easier. These new ease of use features include added functionality for setting registry permissions. The following sections describe how you can keep the settings for your application secure.

Using the RegistryPermission Class

The RegistryPermission class provides code access security for the registry as long as you implement it correctly. The operative words are code access and correctly . The “A Word about Registry Security” section points out serious flaws in the implementation of the RegistryPermission class. The most serious issue is that it doesn’t actually affect the registry. You can still use any unmanaged application such as the Registry Editor to access the keys and their values. The second problem is that you must implement the security correctly, which leaves a lot of room for error. Listing 4.5 shows the code for this example. (The listing for this example contains only the essential information. You can find the full listing for this code in the \Chapter 04\C#\RegSecure or \Chapter 04\VB\RegSecure folder of the source code located on the Sybex Web site.)

Listing 4.5 Implementing Code Access Security for the Registry

class AccessReg { // Some global

variables

used to make registry access easier. private RegistryKey HKey; // HKEY_CURRENT_USER reference. private RegistryKey CKey; // Company key reference. private RegistryKey AppKey; // Application key reference. private RegistryPermission RegPerm; // Registry permission object. private Boolean RegStat; // Registry lock status. public AccessReg() { // Permission for the company registry setting. RegPerm = new RegistryPermission(RegistryPermissionAccess.AllAccess, @"HKEY_CURRENT_USER\Software\" + Application.CompanyName); // Permission for the application registry setting. RegPerm.AddPathList(RegistryPermissionAccess.AllAccess, @"HKEY_CURRENT_USER\Software\" + Application.CompanyName + @"\" + Application.ProductName + @"\0"); // Ensure access initially. RegPerm.Demand(); // Get the HKEY_CURRENT_USER key. HKey = Registry.CurrentUser.OpenSubKey("Software", true); // Verify the company key exists. CKey = HKey.OpenSubKey(Application.CompanyName, true); if (CKey == null) CKey = HKey.CreateSubKey(Application.CompanyName); // Verify the application key exists. AppKey = CKey.OpenSubKey(Application.ProductName, true); if (AppKey == null) AppKey = CKey.CreateSubKey(Application.ProductName); } public void Finalize() { // Close the keys. AppKey.Close(); CKey.Close(); HKey.Close(); // Clear the references. AppKey = null; CKey = null; HKey = null; } public void WriteData(String Value, String Data) { // Check the registry lock status. if (RegStat) RegPerm.Deny(); else RegPerm.Assert(); try { // Write data to the registry. AppKey.SetValue(Value, Data); } catch (SecurityException SE) { // Display an error message. MessageBox.Show("Write Access Denied", "Security Error", MessageBoxButtons.OK, MessageBoxIcon.Error); } } public String ReadData(String Value) { // Check the registry lock status. if (RegStat) RegPerm.Deny(); else RegPerm.Assert(); try { // Read data from the registry. return (String)AppKey.GetValue(Value); } catch (SecurityException SE) { // Display an error message. MessageBox.Show("Read Access Denied", "Security Error", MessageBoxButtons.OK, MessageBoxIcon.Error); // Return an error string. return "Key Access Error!"; } } public void LockRegKey() { // Lock the registry key. RegStat = true; } public void UnlockRegKey() { // Release any registry key lock. RegStat = false; } }

The AccessReg class shows a number of tasks you can perform using the Microsoft.Win32 .RegistryKey and System.Security.Permissions.RegistryPermission classes. Yes, for whatever odd reason, Microsoft decided to place the two registry classes you need to use together in completely separate locations.

The code begins by creating RegPerm , the registry permission for the key used to store registry data for this program. The RegistryPermission constructor call creates a path to the company registry key. The code uses the AddPathList() method to add the application key to the list. You must include both paths to provide an adequate level of security. Otherwise, a caller could access the company key first, and then use that key to access the application key. The AccessReg() constructor uses the RegPerm.Demand() call to ensure the caller has the proper registry rights.

This portion of the code ends by opening three registry keys using the OpenSubKey() method. The first key accesses HKEY_CURRENT_USER\Software\ , which is always available. The second key accesses the company key. If the company key is unavailable, then the code uses the CreateSubKey() method to create it. The third key is the application subkey . Like the company key, the code creates this key if it isn’t available.

The code includes a Finalize() method. All that this method does is ensure that the registry keys are closed and the global variables cleared. Otherwise, strange things can happen when you try to access the registry. One common error is that the key becomes unavailable, even though you know it’s in the registry.

The WriteData() and ReadData() methods are essentially the same. Both methods begin by inspecting a local variable, RegStat . This value determines when the registry is locked or opened to the current application. If the registry is locked, the code executes RegPerm.Deny() , which blocks access to both the company and application keys. Otherwise, the code uses RegPerm.Assert() to ensure the code can access the registry values. The code then uses the SetValue() method to write information to the registry or GetValue() to read information from the registry.

A Word about Registry Security

Securing the registry is important because it contains entries crucial to your machine’s functionality. Registry security in the Win32 API world depends on the RegSetKeySecurity() and RegGetKeySecurity() functions. The Win32 API also requires use of functions such as RegOpenKeyEx() and RegSetValueEx() to interact with the registry. You can find a list of these functions at http://msdn.microsoft.com/library/en-us/sysinfo/base/registry_functions.asp .

The Microsoft.Win32.RegistryKey class provides access to the registry without relying on Win32 API or Platform Invoke (PInvoke) calls. You can learn more about this class at http://msdn.microsoft.com/library/en-us/cpref/html/frlrfMicrosoftWin32RegistryKeyMembersTopic.asp . The System.Security.Permissions.RegistryPermission class provides code access security for your .NET application. However, the security measures leave the registry wide open to attack from any unmanaged application that happens along because this class doesn’t actually lock the registry.

To actually lock a registry key from prying eyes, you’d need an equivalent for the RegSetKeySecurity() and RegGetKeySecurity() functions. Consequently, if you really want to protect the registry, you need to use PInvoke calls. The “Using the RegGetKeySecurity() and RegSetKeySecurity() Functions” section of Chapter 15 demonstrates use of these two calls in securing the registry.

The massive holes in registry security aren’t limited to problems with physical locking and code access only security. If you don’t lock every path for a particular registry entry, it’s possible to use the RegistryKey class to access the value even though your code supposedly locked it. Read the “Canonicalization Problems Using Deny” write-up on the Deny() method at ms-help://MS.MSDNQTR.2003FEB.1033/cpguide/html/cpcondeny.htm for a fuller explanation of the problem. (This topic doesn’t appear online, so you need a local copy of MSDN to see it.) In short, you have to be very careful when relying on the .NET Framework to secure the registry. Microsoft may fix this problem sometime in the future.