Exploring Security in .NET - Part I

Introduction

Before exploring the security features of .NET, several questions come to mind, let's take a look at some of these questions:

• What evidence do we have to ensure its trustworthiness?
• How can we be sure that the code is trusted?
• When we request a module, how do we know if the code that is served to us is right or not?
• How can we handle scenarios where we need custom methods for security?

The .NET security model answers all of these questions for us. The .NET framework gathers evidence about assemblies such as where the code is originating from and groups the code into several code groups. It later enforces a security policy based on this accumulated evidence.

Security Features in .NET

The .NET framework and common language runtime provide services and classes for securing our applications. Take a look at table 1.0 which lists security classes available as a part of the .NET framework.

Table 1.0

Let's highlight the key concepts in .NET security. All below mentioned concepts are used some how depending upon the nature of the scenario:

• Code Access Security (CAS)
• Evidence Based Security
• Role Based Security
• Declarative and Imperative Security
• Cryptography

CAS (Code Access Security)

In today’s environment, code does not reside on a static, predetermined location but instead is frequently originating from unknown remote sources and may move from location to location through email or is sent across a network to be downloaded on a remote system. Because the possibilities are endless, the code today can be termed as “mobile code” or “code in transition”. The .NET framework offers a mechanism called Code Access Security that assists us in protecting application systems from malicious code, granting trust levels to the code and allowing codes from unknown locations to run safely on the local system.

The two main concepts in CAS are Code Groups and Permissions, let's examine both of them.

Code Groups

Code Groups are groups of code or assemblies that are brought together on the basis of common or similar characteristics. The information that is used to group the assemblies or code is called “evidence”. Evidence can be anything known about the code such as digital signatures, the URL or the zone from which the code is originated from.

The point of consideration is that the evidence carried out by the assemblies serves as the entry requirement into the code groups. This is called the "Membership Condition". Every assembly must match the group’s membership condition in order to belong to that code group. Please note that only one membership condition exists for every code group.

Some of the group membership conditions are listed below:

• Zone: A zone is a region from which the code originated, it can take any value from the following:
  • MyComputer
  • Intranet
  • Trusted
  • Untrusted
• Site: A site is the web site from which the code is originated.
• Publisher: The publisher of the code.
• URL: The specified location from where the code is originated.
• Hash Value: The hash value (a value represented as a binary string computed by the cryptographic algorithm).
• All Code: No specific condition, all the codes belong to this category.
• Custom: A condition specified by the user.

Permissions

Permissions are the actions each code group is allowed to perform such as accessing any local resource or user interfaces. The system administrator usually manages permissions. The primary uses of permissions are as follows:

• Code can request the permission it either needs or could use. The .NET framework security system will grant these requests depending upon the evidence of the code.
• It is possible through CAS to make the code insist its callers to have specific permissions.

There are three kinds of permissions as listed below:

• Permissions under the Code Access Permissions category provide access to protected resources and facilitate the performance of restricted operations. Code Access Permissions are derived from the CodeAccessPermission class which itself is derived from the Object class . For instance, the EnviromentPermission built-in class allows us to read or write environment variables.
• Permissions specifying that the code has authorization that supports a particular kind of identity fall into the category of the Identity permissions. One instance of an Identity Permission class is URLIdentityPermision class, which is used to identify the URL from where the code originated.
• Permissions providing a mechanism for discovering whether a user has a particular identity or is a member of a specified role are called Role based security permissions.

Custom Code Access Permissions

Typically, for most environments, built-in code access permissions are more than sufficient. However, in some situations, we may need to define our own code access permission classes. If we wish to define a component or class library that accesses a resource not covered by the built-in permission class but needs protection from unauthorized code, we need to create a custom code access permission.

If you wonder what that situation may be like, consider a scenario in which you have an application that uses students' performance records where each student record is stored in a specified file. In such a case, read and write access must be controlled indecently on different types pf student data. Since the class FileIOPermission only controls access to the file as a whole, custom code access is needed. Custom code access permissions are also appropriate when a built-in permission exists but is not defined to protect resources in a way that we want.

Code Access Security controls the access, as code has to protect the resources and operations.

Evidence Based Security

Evidence is information gathered about code or assemblies based on the questions raised by the security policy. once this information is accumulated, the security policy can grant permissions to a code.

Thus evidence can be anything known about the code such as digital signatures, the URL, the zone that the code is originating from and so forth. The CLR and the host of the application domain gather the evidence.

Three kinds of hosts are provided by default namely:

• Microsoft Internet Explorer
• ASP.NET
• Shell Host (e.g.: CMD Console)

Once the host and the CLR have gathered all the evidence, it is submitted to the security policy as a set objects encapsulated in a single collection object of type Evidence.

Figure 1.0 shows how evidence is gathered:

A simple example of an evidence can be a URL for an ASP.NET application.

Evidence based security works in tandem with Windows logon security. If we attempt to run a .NET desktop application, it must be granted the relevant .NET code access security permissions. However we as the logged-in user must also be running under a Windows account that has the relevant permissions to execute the code. Most application code does not need evidence based security explicitly since it is usually handled by the standard .NET libraries. One thing that an application can do to use evidence–based security is to include a permission request, this will ensure that the code will only run and that the code gets only those permissions it expects to have. Other situations that can make use of evidence based security are listed below:

• Limited access public API: for instance, to make public API that only other code from our site can call or only the code signed with a certain key can use.
• Resource protection: when we define a class library that exposes resources need protection we can define permissions and the security policy system can restrict access.

Managing Security Policies

A security policy as we already know is a set of rules and regulations set by an organization that determines the type of internal and external information resources users can access, the kind of programs they may install on their own computers, as well as authority for reserving network resources.

By the way, default .NET security policy does not include custom permissions. To update the security policy so that it knows about custom permissions, we need to do three things:

• We must make the policy aware of the custom permissions.
• We must add the assembly to which we want to grant the custom permissions to the list of trusted assemblies.
• We then must inform the security policy about the code that should be granted the custom permissions.

Conclusion

In the next part, we will be examining role based security, imperative and declarative security, and ASP.NET web based security. Moreover, we will explore the command line tools namely capol.exe and permview.exe that work with code groups and permissions at various security policy levels.