Exploring Security in .NET: Part I

Introduction

Before exploring the security features of .net several questions come to mind , lets take a look at some of these questions

• What evidence do we have to ensure its trustworthiness?
  
  
• How can we be sure that this 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 .net framework.

Table 1.0

Lets highlight the key concepts in .net Security , all below mention concepts are used some how
Depends upon the nature of scenario.

• Code Access Security (CAS)
• Evidence Based Security
• Role Based Security
• Declarative and Imperative Security
• CAS (Code Access 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 , lets 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 use is used to group the assemblies or code is called "evidence" . Evidence can be anything know about he 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 severs 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

1. My Computer
2. Intranet
3. Trusted
4. 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.

Code groups are arranged in the hierarchical manner . the code group situated at top of the hierarchy is called "All Code" and contains all code groups. The hierarchy is used in deciding the code groups to which as assembly belongs. Determining the code group to which an assembly belongs is dome by matching the evidence provided by the assembly with that of the existing code groups in the tree.

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 insists 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 CodeAccessPermission class which itself is derived from Object class . For instance the EnviromentPermission build-in class allows us to read or write environment variable.
  
  
• 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.

The .net framework provides a set of code access permission classes that are designed to protect a specific set of resources and operations.

Custom Code Access permissions

Typically , for most environments , build in code access permissions are more than sufficient .How ever , 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 access a resource not covered by the build in permission class but needs to protected from unauthorized code , we need to create a custom code access permissions.

If you wonder what that situation may like consider a scenario in which you had 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  of  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 build in permission exists but is not defined to protect resource 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 permission to execute the code. Most application code does not need evidence based security explicitly since it is usually handled my the standard .net libraries .One thing that 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 protecting: when we define a class library that exposes resources need protection we can define permissions and the security policy system to 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 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 works with code groups and permissions at various security policy levels.

NOTE: THIS ARTICLE IS CONVERTED FROM C# TO VB.NET USING A CONVERSION TOOL. ORIGINAL ARTICLE CAN BE FOUND ON C# CORNER (WWW.C-SHARPCORNER.COM).