Controlling Access

The .NET Framework provides features that control both code and user access to various resources. However, these are new techniques for most developers and poorly explained in many situations. Chapters 4 and 5 discuss the actual mechanics of access control. For now, what you need to know is what issues you’ll face when you use these technologies in your application.

Understanding Code Access Control Issues

Any code you created before .NET usually had free reign over any resource the system had to offer (and it could obtain). Unrestrained code has caused a number of problems throughout the history of the PC. For example, I still remember when I had to set multitasking environments to restrict the memory available to applications or they would attempt to grab every byte.

Resource problems aside, unrestrained access can result in other problems. It wasn’t too long ago that code would overwrite the memory used by other code. Until processor technology stepped in to ensure that applications had to behave themselves, this problem looked like it would kill any hope of creating a usable environment where multiple applications could reside unmolested. Now, consider for a moment that some of these applications are still around and you understand why code access security is so important.

When you write a program using the .NET Framework, you need to ensure that it doesn’t step on any other application’s toes. This means checking everything from resource use to the kind of access the code enjoys. If a code doesn’t need to access a data stream, don’t give it access to that stream. When a cracker comes along and tries to get your code to perform some nefarious task, the code won’t be able to comply. Limiting access isn’t about restricting performance or creating less capable programs—it’s about locking your system down so that crackers can’t abduct it.

Understanding User Access Control Issues

Some network administrators and many developers have the wrong idea about user access control. For some people, it’s a power issue, but I won’t get into that little problem here. The real reason you control user access to system resources is to protect the user. When a user gains unnecessary access to system resources, data, or environmental control, the system can crash, taking the user’s data with it.

Most developers don’t spend a lot of time with users. However, by defining company-endorsed roles for users and then enforcing the required level of access for each role, your application can keep the user out of trouble.

This control extends to keeping crackers out of the user’s account. By limiting user access to specific roles, you limit the appeal of the account to those who would use it for less than honorable reasons. In sum, the issue you face when it comes to user access control is how best to define roles that will meet every need for that particular application.

Setting Privileges Appropriately

One of the most pressing security issues is that of access. Many companies have security problems because they lack proper control of privileges. Any user who thinks they need access to a resource often gains access to that resource without much of an argument. When a cracker creates an exploit, programming problems often grant initial access to the network. However, the lack of proper controls makes the problem worse by giving the cracker more access. A programming problem that causes a slight breach becomes worse when the cracker uses a regular user’s account to gain access to administrator level resources.

You can avoid at least some of the security problems faced by other developers by incorporating a certain level of security within your application. The use of role-based and code access security won’t mean that your application is bulletproof, but these security features do make it less likely that your application will become the source of a major security breach. The idea is to control access to resources programmatically whenever possible. Privilege can become a double-edged sword. On the one hand, granting appropriate privileges make users more productive, but they also leave doors open that crackers are almost certainly going to use.