Introduction

Windows is a secure OS. The security offered by the OS protects the local machine from any unauthorized user operation. Each secured resource under the OS, such as the Windows registry or an NTFS file, can be configured to allow access to some users, while denying access to others. This approach, however, fails to address an important security issue: users acquiring and running third-party applications that potentially could be malicious. Today, users obtain the applications from many sources. They have no idea what the application code does internally. The code may delete some important files on the local disk. Worst yet, the code may leak your private data. The quality of the code may be poor; it might contain bugs or vulnerabilities that some other malicious code may take advantage of. The ease of downloading components over the Internet has exacerbated this security issue.

Microsoft has put a lot of thought into designing the .NET Framework so that the number of bugs can be reduced in the code that you develop. Here are some examples:

• A common source of security bugs is that developers fail to check the error codes. Under .NET, all the standard classes throw exceptions in case of an error. This forces developers to check the error conditions.

• Array bounds are always checked, eliminating many sources of buffer overruns.

• All variables are guaranteed to be initialized. This avoids people being able to read random bits of memory.

• During JIT compilation, by default a verification process examines whether the metadata and the MSIL instructions of the method to be JIT compiled are type safe (there is a way to override this default behavior using a security action called SkipVerification, which we will see later). Type-safe code can access only the memory locations that it is authorized to access. It is disallowed from accessing all other memory locations. This isolation helps ensure that assemblies can execute in the same process without adversely affecting each other.

Although these built-in precautions are good security measures, they don't (and cannot) address the fact that a third-party assembly may contain malicious code.

To ensure that untrustworthy assemblies do not harm your computer, the .NET Framework provides a security mechanism called Code Access Security (CAS). Based on CAS, code obtained from unknown origins can be configured to run with restricted permissions, thereby reducing the chances of the code being able to harm your computer. For example, if you were visiting a Web page that caused managed code to be downloaded and run on your local system, CAS would prevent it from formatting your hard drive even though you, as the user, might have the appropriate Windows NT permissions to do so.

The CAS mechanism enforces security based on the identity of the code, not that of the user. There are times, however, when an application may wish to make security decisions based on the user's identity and group membership. To address this, .NET provides another security mechanism referred to as role-based security. This security mechanism enables the code to make security decisions based on the role the user belongs to.

The relationship between OS security and .NET security can be envisioned as three levels, each level influencing the ones above it, as depicted in Figure 9.1.

Let's look at the concepts underlying CAS and role-based security.