.NET Framework Security Architecture Considerations

It’s important to know something about the .NET Framework security architecture and determine how you can use that architecture to fix problems. You also need to know about issues and problems you’ll face as a result of the architectural decisions that Microsoft has made. This section of the chapter discusses some architectural issues you need to consider before you begin coding. You’ll learn about other architectural considerations (practical versus theoretical) as the book progresses.

Note

Microsoft has improved the .NET Framework security features in Version 1.1, the version that I use for this book. Some of the calls in the example programs for this book don’t appear in the .NET Framework 1.0. I’ll let you know when you’ll need Version 1.1 in most cases. However, if you run into a call that obviously isn’t in the version of the .NET Framework you’re using, make sure you update to the most current version.

Securing the Binary Output

Securing text usually isn’t as big a problem for organizations as securing binary information. All you need for text is a good encryption technology and the code to use it. Binary data is entirely different because it usually involves complex protocols and can include code. In fact, security of some older technologies, such as DCOM, makes securing binary data almost impossible. The problem is that these older technologies often use ports indiscriminately and require the data in an unencrypted form to ensure the recipient can read it.

The .NET Framework makes it easier to secure binary data. Not only does it avoid the problem of using multiple ports, it also provides methods for encrypting and decrypting data as part of the serialization stream. You can also rely on code access security to help in this situation by controlling the BinaryFormatter object. All you need it a set of permissions to go with the serialization and de-serialization process. A permission could be as simple as adding the following attribute to your code:

[SecurityPermissionAttribute(SecurityAction.Demand,SerializationFormatter=true)]

If the code doesn’t have the proper permissions, CLR won’t allow the BinaryFormatter to do anything. Of course, you could just as easily use imperative security (the SecurityPermission class) to achieve the same goal.

Understanding the Effects of Garbage Collection

Garbage collection is a wonderful idea. It means that you spend a lot less time worrying about memory allocation and freeing resources. The Garbage Collector takes care of freeing these resources for you. Of course, you can always step in and dispose of objects when necessary. In fact, this is a recommended procedure when you have large objects and aren’t sure when the Garbage Collector will kick in.

The Garbage Collector also impacts security because it affects memory and resources. What happens if a cracker wants to look around in memory and determine what’s going on or look for some interesting data? Your program might think that data’s already gone, but there it is, in memory waiting for the Garbage Collector. The issue of waiting for the Garbage Collector is normally not something you need to consider, but it is if the object concerned contains sensitive data.

From an architectural perspective, the Garbage Collector is probably the best thing to happen to developers in a long time. However, from a security perspective, it’s a problem because objects have an indeterminate life span. The solution, in this case, is to build your sensitive objects with methods for disposing of the sensitive information. You should then build your code so that it always frees objects immediately. Freeing the objects will get the Garbage Collector busy immediately, rather than waiting for the program to exit.

Considering the Requirements of Object-Oriented Programming

One of the best reasons to use .NET to build secure applications is that it’s fully object oriented. You can attach security to every element of your program. The security system will faithfully check every access to every method, property, and event of every object your application creates. In general, you can bind your .NET application to the point where nothing can get in—at least not directly.

The problem with .NET security is that every access requires a stack walk and that takes time. The .NET Framework has some optimization built in to reduce the number of complete stack walks, but the basic idea is that security demands that permissions get checked every time a request is made. This level of checking makes .NET secure, but it also makes .NET slow.

As the book progresses, you’ll learn several methods you can use to keep speed problems to a minimum. For example, using declarative security, whenever possible, will speed your application because some declarative security requirements are handled at link time, rather than runtime. In addition, declarative security attaches the security to the method, rather than to the object, whereas imperative security is handled completely at runtime and focuses on the objects you create in the code.

Understanding Native Code Access Concerns

Just about every developer has a wealth of native Windows code to consider as part of any application development task. Most developers have concluded that they’ll need to use PInvoke to continue using the unmanaged code that they’ve spent so much time and resources developing. However, what happens when you mix managed and unmanaged code in the same project? Obviously, the unmanaged code won’t understand role-based security or code access security.

Tip

Creating PInvoke code can become difficult if you use complex data structures and require access to some of the less documented Win32 API features. You may also want to move your components and controls from the unmanaged to the managed environment. My book, .NET Framework Solutions: In Search of the Lost Win32 API (Sybex, 2002, ISBN: 0-7821-4134-X) can help you overcome any of the problems you’ll run into when working with the Win32 API.

One solution to this problem is to use Win32 API security for the entire application. In fact, that’s what many developers are doing now because that’s what they understand best. Knowing that your application employs the same security techniques across all elements can add a bit of comfort in a world that’s increasingly insecure. The benefit of this technique is that it’s relatively easy and fast. You also know the problems involved in using this method, so you can easily watch for them as you maintain the security of your system.

Another solution is to place the managed code within a separate domain. This is the solution that affords you the best chance of catching problems early. The .NET Framework security is definitely more robust than the security used by your Win32 API code. The advantage of this method is obvious: greater security is always a good thing when you can get it. However, there are several disadvantages to consider:

• For one thing, there’s a performance hit for placing the individual code elements in separate domains.

• You’ll also have to consider the problems of maintaining two different security techniques until you make all of your code managed. Complexity always breeds errors, which is anathema for secure systems.

In sum, the .NET Framework architecture gives you two basic choices for handling security when you have a mix of managed and unmanaged code—a condition that will exist for quite some time in the Windows community. What you need to consider are the trade-offs between the two choices. Neither choice is a perfect solution, but one choice might work better than another for your particular application.

You also need to consider some types of native code access in light of the way that .NET handles objects. CLR checks every object for security violations, even those accessed through the interoperability layer. In some cases, you can get a performance boost for your application and reduce interoperability issues by removing these runtime checks using the [SuppressUnmanagedCodeSecurity] attribute.