Before exploring the security features of .NET, several questions come to mind, let's take a look at some of these questions:
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.
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.
| Security Class | Description | Can be inherited | Parent Class |
|---|---|---|---|
EnviromentPermission |
This class deals with the creation/updating of System and User environment variables. | No | CodeAccessPermmision |
UIPermission |
This class controls the ability to use user interfaces and the clipboard. | ||
FileIOPermission |
This files deals with the ability to access files and folders. | ||
SecurityPerssion |
This class defines a collection of security permission flags used by the .NET framework security system. | ||
PrincipalPermission |
This class allows us to perform checks against the active principal using language constructs defined for both declarative and imperative security actions. | No | Object |
GenericPrincipal |
It is the basic implementation of IPrincipal representing any principal. This class allows code to check role memberships of the user represented by GenericPrincipal object. |
Yes | Object |
GenericIdentity |
An object of this class represents the user on whose behalf the code is running. | Yes | Object |
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:
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 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:
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:
There are three kinds of permissions as listed below:
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.
URLIdentityPermision class, which is used to identify the URL from where the code originated.
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 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:
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:
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:
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.
| You must Sign In to use this message board. | ||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
