Security Choices for Developers and Administrators

This article has been excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors of C# Corner.

Code access security and role-based security are the two main types of security available to developers. Code access security deals with assigning permissions to code, which allows code to access protected resources (such as disk files or the registry) or carry out certain operations (such as accessing unmanaged code). Code access security is built around the notion of permission objects, which control who can access protected resources and what level of access is granted. These permissions are usually based on a permission policy specified by administrators on a given machine or domain.

Role-based security deals with identifying the user who is attempting to execute the code, allowing or disallowing certain operations based on the privileges that the user possesses. User identity is the underlying notion, but role-based security also deals with permissions. Identities are closely tied to principals, which contain information as to which roles a user has. The .NET Framework provides an extensible architecture that allows developers to build their own principals and identities for use with .NET role-based security.

The .NET Framework also introduces another security model, evidence-based security. Evidence simply refers to input to the security policy about code. Code that targets the CLR is deployed in single - or multiple-file units called assemblies, which are the building blocks of .NET Framework applications. At load time, the CLR examines each assembly for evidence identifying the assembly - for example, the digital signature of the code's author and the location where the code originates. Based on this evidence, the CLR security manager maps the assembly to a code group. Code groups are defined to test for specific forms of evidence and have permission sets associated with them. Assemblies that belong to a code group receive the permissions defined by the associated permission sets.

For illustrative purposes, suppose some assemblies belonging to an application are downloaded to the client computer from a Web site. Based on evidence about the assemblies such as the URL, zone, strong name, and Web site from which the assemblies are downloaded, the security system can determine the proper set of permissions to be granted to the assemblies. Evidence information can be obtained from multiple sources - the CLR, Microsoft Internet Explorer, Microsoft ASP.NET, and the operating system shell, depending on the source of the code.

When an assembly is loaded, the CLR policy system gathers the assembly evidence and evaluates it in the context of the security policy. The CLR policy system then determines which set of permissions it should grant to the assembly based on the evaluated evidence and any specific permission requests that the assembly makes.

Permission requests may be used to stipulate certain permissions or limit the permissions granted to an assembly. Assembly publishers know that some assemblies will operate properly only when granted a certain minimum set of permissions and that other assemblies will never need certain permissions. Depending on the form of permission request, the policy system may grant permissions to an assembly or remove unnecessary permissions. The system may even refuse to load the assembly, if the minimum set of permissions needed to run the assembly is not granted by system policy. An assembly can never be assigned more permission than the policy system would grant in the absence of permission requests.

Security policy consists of a collection of code groups, each with associated permissions to be granted based on the evidence obtained. Policy has two aspects: permissions granted to code rather than to users and permissions granted on a per-assembly basis. Code groups describe the permissions available to assemblies acquired from a specific security zone, or those that are signed by a specific publisher, and so forth. While the CLR ships with a default set of code groups and associated permissions, system administrators can modify these CLR security definitions to fit their needs. Almost any characteristic can be submitted as evidence, provided that the security policy has a use for it. The administrator merely needs to define a code group related to that evidence.

The procedure for granting permission involves evaluating the evidence to determine which code groups are applicable at each of four levels (detailed later): enterprise, machine, user, and application domain. The policy evaluates these four levels in order and then creates a permission set that represents the intersection of all four. System administrators may designate any policy level as final, thus preventing the evaluation of policies at subordinate levels. For example, an administrator can finalize policy for an assembly at the machine level and prevent the application of user-level policies to that assembly. Once the policy processing is complete, an initial set of permissions is created. Assemblies may adjust these grants by making specific requests in three areas:

The first step is to specify a minimal set of permissions that the assembly must have to operate. If these permissions are not present, the assembly fails to load and an exception is thrown.
Next, an optional set of permissions may be specified. While the assembly would like any of these permissions, it still loads if they are not available.
Finally, particularly obedient assemblies may actually reject hazardous permissions that they don't need.

These three enhancement options are accomplished as load-time declarative statements. At runtime, permissions are evaluated based on the execution of code. Actions such as reading or writing files, displaying dialog boxes, and reading or writing environment variables are accomplished using .NET Framework methods that are included within the framework security infrastructure. Thus the .NET Framework allows or disallows actions based on the security policy without imposing additional work on the developer. While programmers of managed classes that expose protected resources must make appropriate security demands in their libraries, programmers who use the .NET Framework class libraries to access a protected resource benefit from the code access security system for free; they do not need to make any explicit security calls.

Administrators may adjust the security policy by determining which permissions are granted and then rely on the .NET Framework to handle all security operations. Code access security prevents most attacks, and the verification of code eliminates buffer overruns and other unexpected behaviors that can lead to security susceptibility. Thus, applications and components are inherently protected against the vast majority of security problems that have plagued native code implementations.

Sometimes it is appropriate for authorization decisions to be based on an authenticated identity or on the code's function. For example, financial or business software may enforce security policy through business logic that evaluates role information. The amount of a financial transaction may be limited based on the role of the user making the request. Tellers may be allowed to process transactions up to a certain dollar amount, whereas a supervisor may need to process transactions involving higher amounts. The .NET Framework provides services that enable applications to incorporate such logic easily, building it around the concept of identities and principals. An identity may map to the user logged into the operating system or may be defined by the application. The corresponding principal encapsulates the identity, along with any related role information - for example, the user's "group" as defined by the operating system.

Conclusion

Hope this article would have helped you in understanding the Security Choices for Developers and Administrators. See other articles on the website on .NET and C#.

The Complete Visual C# Programmer's Guide covers most of the major components that make up C# and the .net environment. The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer.

Security Choices for Developers and Administrators

Reactions

Comments