Exploring Windows 2003 Security: The .NET Framework

The previous article in this series covered software restriction policies, which provide the capability to restrict which applications are executable in Windows XP/200x environments. This determination can be made on per-computer or per-user level based on customizable criteria (such as hash, certificate, path, or the Internet zone from which the software originated).

The .Net platform offers a host of security features. To better understand them, this installment of our Windows Server 2003 Security series provides an overview of .NET Framework, the basis for all .NET-related topics, from a non-developer perspective.

Although this mechanism helps increase security, it does not allow any level of granular access control once a program is running — its access rights are already determined by the level of privileges granted to the user who launched it. Changing this situation required a drastic change in the way software operates.

Microsoft accomplished this change after years of development effort and the creation of the .NET platform. .NET not only revolutionized the way software is designed, but it also increased the stability and security of applications created according to its standards.

However, before we start discussing security features offered by .NET platform, let’s clarify the general principles.

Much of the confusion around .NET has been due to Microsoft’s frantic marketing campaign, which resulted in attaching this name as a suffix to almost every single product released in recent years. What also contributed to this confusion was that .NET is a fairly complex concept, encompassing many technologies and products, and it is difficult to explain to people who do not have some type of software development background.

This article will focus on the .NET Framework, which serves as the basis for all .NET-related topics.

In the simplest terms, .NET Framework is a new runtime environment, which means its main purpose is to provide mechanisms that enable other programs to execute. These mechanisms, built into the framework, are what makes the development process that much simpler and the entire platform more stable and secure. Among the most important ones are:

• Automatic memory management (also known as garbage collection): Most readers are familiar with the term memory leak, which describes a process where an application uses a system resource (typically memory) but does not return it to the system once it completes. This is typically the result of a programming oversight or error. Components of the framework are responsible for tracking how system resources are used and making sure that they are freed as soon as they are no longer needed by applications.
• Code-level security: The .Net Framework enables the system administrator to not only control which applications can execute on the system, but also what level of permissions they will be granted while running (e.g., permitting certain applications to write to files, while restricting others to reading only).
• Standard version management: One of the most common problems with pre-.NET applications running on the Windows platform was the so called “DLL hell.” This term refers to the situation where multiple applications installed on the same computer require different versions of dynamic link libraries (DLLs). Although partial solutions to this problem have been introduced in Windows 2000 (see The Way Out of Your Private (DLL) Hell), they are by no means complete and do not address every possible DLL conflict scenario. With .NET applications, this issue is fully resolved. Applications can specify exactly which version of the supporting files they require. The information is stored in Assembly, which is an intrinsic part of every .NET application.
• Multiplatform support: It is no longer necessary to compile separate versions of the same application for different platforms. For example, in NT 4.0 days, a separate version of the same application would need to be compiled for Intel and RISC platforms. Although the RISC systems are no longer supported (starting with Windows 2000), you would need to use the same approach when dealing with standard Windows applications running on Win32 and Win64 (Itanium) platforms. This need has been eliminated by breaking the compilation of .NET applications into two stages (more about this shortly).
• No more compatibility problems and functionality differences between different programming languages: Microsoft revamped new versions of programming languages (the most commonly used are Visual Basic .NET and C#, but there are many others) used to create .NET applications. The goal was to ensure that programs can freely mix code written by different developers, increasing software reuse and speeding up the development process.

Probably the biggest benefit of .NET Framework is a simplified software development process. Although on the surface this does not seem to be a tremendous advantage from a system management point of view, remember that the overwhelming majority of administrative headaches result from poorly designed software. By providing prepackaged components responsible for handling most critical tasks, such as security or memory management, applications become less-expensive and more stable.

All of the features outlined above result directly from the new architecture in which software operates. (The term “new” is questionable, however, considering that the same approach has been used by Java developers for years.) In the past, traditional Windows programs in the form of a compiled binary code would execute using facilities provided by the operating system. With the new architecture in place, the compilation process has been broken into two stages. This way, .NET applications, instead of being compiled into machine-specific binary code, are first converted into Intermediate Language (IL). IL is platform and programming language independent, which offers two main benefits:

1. The same program can be executed on multiple platforms (e.g., 32-bit and 64-bit versions of Windows 2003), without the need for creating two separate binary versions prior to deployment.
2. Programmers can code in any of the available .NET programming languages, without concern for their compatibility or differences in their functionality, since the resulting IL code is independent of the language used during software development.

IL code is automatically compiled into its binary equivalent (which constitutes the second stage of the compilation process) every time the application is launched. This part of the compilation process produces code is specific to the underlying operating system platform and is handled by the Just-in-Time (JIT) compiler.

In some cases, however, this type of behavior might be undesired due to its performance implications. If that is the case, you can compile the application once, when the application is installed on the computer. This results in binary code being stored locally and eliminates need for just-in-time compilation. JIT compiler is a subcomponent of the central piece of the framework called Common Language Runtime (CLR).

CLR functions as a middle layer between .NET applications (described frequently as managed applications — to distinguish them from unmanaged pre-.NET applications) and the underlying operating system (what type of the operating system that is does not really matter, as long as it supports CLR). By controlling activities of managed applications during their execution, this middle layer is capable of providing all of the previously listed .NET framework benefits.

Note that CLR is capable of managing only applications developed according to .NET specifications: Older programs cannot take advantage of its features.

.NET Framework (currently at version 1.1) comes built into the Windows 2003 server, but it can also be installed on older operating systems, namely Windows 2000, Windows 98, Windows ME, Windows NT (with Service Pack 6a), and Windows XP. To complete the installation, Internet Explorer 5.01 or later is also needed.

A full set of instructions describing the requirements and installation process are provided on the MSDN section of the Microsoft Web site. You can obtain it as part of regular Windows update process, or via the .NET Framework Redistributable package (available as a download or on CD).

.NET Framework is available in versions 1.0 and 1.1. Before deciding which version to install, we recommend investigating any compatibility issues between the two versions. This will depend, to a large extent, on the framework that the applications were designed against. For more information on this topic, refer to the documentation available from Microsoft.

The next article in this series will explore the security features implemented in .NET framework that allow the administrator to control access rights of managed applications running on Windows 2003 server.