Chapter 10: Scalability and Security

---

Without a doubt, Microsoft has undergone a huge change in attitude toward security following an announcement in 2001 that all product feature development would cease for six months while the product groups reviewed the security aspects of their products.

Scalability has always been an issue for Microsoft, as they start to penetrate enterprise-level applications. The ability for the software to grow inline with business requirements is one of the first issues raised by corporate IT departments. Windows NT was introduced a few years ago with the objective of providing the first scalable platform from Microsoft. Over the years, the platform has inevitably been enhanced, and with Windows 2000 we see a scalable enterprise operating system from Microsoft.

10.1 .NET Security

As you would expect, .NET comes with a lot of security built into the underlying framework. The security in .NET is based upon the concept of managed code, with the security of the code being looked after by the (CLR see Chapter 3). Managed code is checked to ensure that it is type-safe, so that incorrectly calling a method declared as accepting an 8-byte value will reject a call from anything larger as not being type safe. This verification process also ensures that code executes using flow transfers to method entry points or other well-known locations rather than some random location.

The CLR does allow unmanaged code to run, but it will not manage any of the security of the application, and specific permissions need to be granted to allow calls to unmanaged code. Microsoft believes that .NET managed code will soon become the norm as the benefits become realized by developers and the incidence of unmanaged code decreases over time.

10.1.1 Role-Based Security

This is the model used by .NET to authorize and authenticate users. It uses the idea of a principal, who is the user on whose behalf code is run. The security model is also responsible for the authentication of the user name/password pair submitted by a principal.

A principal may be a member of a group of users that have a set of activities they are authorized to do, and these roles are examined when a user attempts to undertake a privileged operation. Roles include backups, adding new users, and accessing specific directories.

10.1.2 Evidence-Based Security and Managed Code

It's all very well trusting users, but what happens if Mrs. Miggins brings in a floppy disk from home with some code on it written by her son. Trusting code and restrictions on how code is executed are a basic part of how .NET is structured to ensure that rogue code does not trample over a user's machine, causing damage. Managed code-that is, code running within the .NET framework-can be limited to using well-defined interfaces. Applications can be built that run a host of components in the knowledge that security can be enforced at differing levels, according to the nature of the application. All of this code can run in-proces; the code permits previously risky scenarios, such as code for mobile devices, to be downloaded from insecure servers and executed safely, knowing that the code is subject to restrictions.

For managed code to run, a security policy will assess which permissions to grant based upon evidence from the code assembly and any specific requests from the code itself. The collection of evidence can be from a number of sources, including the site URL, the zone the code is from, or the existence of valid digital signatures.

Other evidence sources include the following:

• The hash value of an assembly generated with hash algorithms.

• The strong name signature of an assembly. Strong names represent a versioned, cryptographically strong way to refer to and identify an assembly or all assemblies of a particular signing party. They do not provide any authentication of the author, but they uniquely identify the assembly and ensure that it has not been tampered with.

• The site from which the code came. Assemblies are the building blocks of .NET framework applications. They form the fundamental unit of deployment, version control, reuse, activation scoping, and security authorization. An application's assemblies are downloaded to the client from a Web site.

• The directory from which the code is loaded.

• The Authenticode digital signature of the assembly.

If the code attempts to perform a function outside of the scope of its approved security rating, then quite simply the code won't run. Code can be examined at deployment time to see what permissions are required for it to run successfully.

In reality, most code that a developer writes would not need to use the evidence-based security explicitly, since that is looked after by the standard class libraries within the application. Whether or not the security model is used explicitly, developers can be assured that it is there anyway and that the entire application runs in the context of the evidence-based security model.

---