Fundamental Security Benefits from the .NET Framework

for RuBoard

The simplest software targets low-level hardware. Creating such software involves "writing to the bare metal." This can be rather difficult and cumbersome, but it gives the best potential performance and flexibility. Typically, such coding occurs using assembly language targeted at a specific CPU's instruction set. Unfortunately, this makes software-enforced security nearly impossible due to complexity constraints.

One of the many benefits of an operating system is that it provides security mechanisms not easily provided in small, low-level applications. For example, an operating system defines the notion of user accounts with different privileges so that some users can be restricted from reading data belonging to other users or using certain resources.

However, this is not always sufficient for our needs today. Sometimes, providing different privileges to different applications is useful, too. That is where the .NET Framework comes into play. As described in Part II of this book, "Code Access Security Fundamentals," the .NET Framework provides a way for different applications run by the same user to be automatically granted different levels of trust.

It is important to note that the .NET Framework is meant to be a layer above an operating system. This gives it the ability to leverage existing security mechanisms in addition to providing additional security enforcement through Code Access Security. Chapter 4, "User- and Code-Identity “Based Security: Two Complementary Security Paradigms," covers the difference between operating system security and .NET Framework security in more detail.

Managing Code Execution

As discussed in Chapter 2, "Introduction to the Microsoft .NET Developer Platform," the .NET Framework has several tools it uses to manage code execution. When loading an assembly, it can verify the type safety of the IL and ensure that its metadata is valid. (See Chapter 11, "Verification and Validation: The Backbone of .NET Framework Security," for more details on IL and metadata checking.) As long as no calls are directly made to native code, this alone can be a huge security win because it can prevent bad pointer manipulation. In addition, the use of garbage collection helps stop runaway resource leaks that have been the source of denial-of-service attacks in some software.

One big benefit of managed code is that bounds checking is automatically performed on array accesses . This means that buffer overflows are nearly impossible to accidentally create in managed code. This doesn't automatically make managed code secure, but it sure helps with problems we've been seeing in today's software environment.

Additional Security Enforcement

The .NET Framework is by no means the first environment to provide a managed layer (using a virtual machine or Just-In-Time compiler) for applications to target. However, it does add some unique benefits to the managed environment. Specifically, Code Access Security is a powerful tool leveraged by the .NET Framework. Stack walks, discussed in Chapter 7, "Walking the Stack," check for fine-grained permissions on each caller to ensure that maliciously written .NET applications cannot step outside their set of granted permissions. Permissions in the .NET Framework are discussed in Chapter 6, "Permissions: The Workhorse of Code Access Security."

NOTE

As you might imagine, security stack walks can hurt application performance. If the trust of all callers on the stack can be verified by fully trusted code, stack walks can be terminated early, minimizing the performance impact. Performance and security can be at odds with each other when you are writing software, and this is an example of the tradeoffs to consider. In many cases, the .NET Framework has been designed to emphasize safe programming practices, which sometimes come at the expense of better performance. Extreme caution should be taken when trying to optimize performance at the expense of security.

In addition to providing the stack-walking engine of CAS, the .NET Framework provides a flexible policy engine to ensure that administrators have the ability to express customized statements about what trust to provide to any given code. Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy," covers the internals of CAS policy. Without the ability to give detailed policy statements, CAS would be less useful because granularity of permission grants would be hard to achieve. Part IV of this book, ".NET Framework Security Administration," covers how administrators can tailor the .NET Framework for their particular organizations. In particular, Chapter 18, "Administering Security Policy Using the .NET Framework Configuration Tool," and Chapter 19, "Administering .NET Framework Security Policy Using Scripts and Security APIs," cover how to administer CAS policy.

for RuBoard