Chapter 4: .NET Role-Based Security Techniques

Overview

• Defining the Differences in .NET Role-Based Security

• Detecting Permissions with the Permission View Tool

• Working with the .NET Framework Configuration Tool

• Developing Applications that Use Declarative Security

• Developing Applications that Use Imperative Security

• Creating a Secure Registry Environment

• Creating a Secure Desktop Application Installation

• Developing Managed Components and Controls

• Testing Your Desktop Application

The vast majority of the non-code security problems that you’ll encounter are user oriented because users are unpredictable and they don’t follow rules particularly well. Users cause problems by writing down their passwords, believing crackers performing social engineering exploits, and downloading materials that look interesting, but contain deadly code. However, a program is essentially useless without a user. Why write something that someone can’t use to perform useful work? One of the ironies in life is that the applications designed to service user needs are the very applications that require the greatest protection from the user.

Note

Social engineering is an extension of psychology where the cracker exploits a common human attribute such as curiosity to obtain useful information, convince the user to comply with specific requests, simply use the person as a tool for breaking into the system. You can find an excellent paper on the topic of social engineering at http://www.securityfocus.com/infocus/1527.

This chapter won’t show you how to control users—that’s impossible. While it’s true that training can help users become more aware of the consequences of their actions, it’s very hard to convince a user to apply the training they’ve received unless the user is willing to do so. (A good whip can also help, but don’t let human resources catch you in the act.) However, this chapter does show how you can use role-based security to reduce the risk to applications, resources, and data from users by giving the user access based on the role they must perform. In some cases, the chapter also discusses how you can attempt to mitigate some of the problems that stem from less reliable and dependable users. For example, you can issue some types of access based on the user’s ability and willingness to use the access carefully. In many cases, you can base your assessment of the user’s behavior on their historical pattern of use.

You’ll also learn a few code access techniques in this chapter. These techniques relate to the use of code access to offset some of the problems that role-based security can’t address adequately. If you can’t keep the user from creating a security breach, perhaps the code can at least make the security breach less severe or even prevent it from occurring in the first place. Code access security is an essential tool in the war on security problems. You really do need to combine both security techniques, along with good coding practice, to achieve a secure system. (Make sure you read about the problems developers have in Chapter 3 before you judge the user too harshly based on this introduction—developers can play a big part in security problems too.)