While developing an IT system, or just an application for the .NET Framework platform, one is likely to face the task of implementing mechanisms of security, permissions, authentication and authorisation. This article describes some aspects of such usage.

While developing an IT system, or just an application for the .NET Framework platform, one is likely to face the task of implementing mechanisms of security, permissions, authentication and authorisation.

At that point there are at least three possible approaches to choose from:

• brush the problem off or ignore it altogether,

• implement a custom security model,

• take advantage of security mechanisms built into .NET Framework

For obvious reason, the first approach is hardly a good one. The second one might be acceptable, then again it will require large amounts of time and effort. Last but not least, the third one usually turns out to be the best one… why?

An integrated security system

The .NET Framework platform contains an integrated security system providing administrators, programmers and end users with a consistent, uniform and transparent security model, all the necessary administrative tools and documentation. One might say - why bother with all that? After all our company is already protected by access passwords, firewalls, anti-virus scanners etc. However, one should bear in mind that in the great majority of cases the weakest link in the security chain is humans themselves. Quite frequently users use resources coming from many unknown sources - e.g. documents, e-mail attachments, Web sites or FTP. Such resources can contain malicious code or flaws which make them useful in attacks against, destruction of or theft of data. The security system in .NET Framework allows setting restrictions on application permissions depending on the trustworthiness of their source of origin. By default, every application coming from the local computer possesses a full set of permissions (Full Trust) which grants them access to all the resources of the computer. On the other hand, applications coming e.g. from the LAN or from the Internet have their permissions restricted from the beginning. Of course .NET Framework provides the means of flexible configuration of which sources of origin are trusted and to what degree, as well as to grant permissions to applications coming from particular sources. Implementation of mechanisms of authorisation and authentication that enforce presentation of user credentials in an application (e.g. by providing a login and a password) and restrict access to various features depending on the roles assigned to the given user, is important too. Here assistance is given by the platform itself, through the ability to control permissions depending on roles (Role-Based Security), together with mechanisms of identification and identity.

Security Policies

A security policy is the basis and the foundation of all the security mechanisms built into .NET Framework. Security policies are configurable and extensible definitions of conditions, basing on which the CLR grants appropriate permissions to every loaded assembly. Security policies can be set and modified by the administrator through the .NET Framework configuration tool - mscorcfg.msc (a snap-in for the management console MMC) - and the tool called caspol.exe (available from the command line).

A security policy consists of four main elements:

• Security Policy Levels

• Code Groups

• Named Permission Sets

• Permissions

In order to understand exactly the purpose and significance of these elements, as well as the dependencies between them, let us begin with the last one:

Permissions - that is, definitions of permissions which the CLR can grant loaded assemblies which match conditions defined by the security policy.

Permissions can be segregated into three groups:

• Code Access Permissions

• Identity Permissions

• Role-Based Security Permissions

Code access permissions - they allow protection of resources and access to restricted operations against unauthorised use by untrusted assemblies. .NET Framework provides a series of built-in access permissions to files, the registry, the user interface, calls of non-managed code etc., thus making it possible for the administrator to restrict any assembly's access to various resources of the computer. The programmer on the other hand is able to implement explicit dropping of permissions the application doesn't require but which have been granted to it. Such approach allows one to limit permissions possessed by the application to the minimum that is necessary for its proper operations - which in turn decreases the risk of the application being exploited by malicious code (a virus, a trojan etc.) through flaws in its code in order to attack the machine the code has been run on. Additionally, the programmer is capable to simulate lack of permissions to access certain resources on his own computer, thus verifying behaviour of the application under such circumstances. In other words, the programmer is capable of testing the application in conditions more closely resembling its deployment environment.

Identity permissions - they are granted on the basis of Evidence, which may consist of various information about the origin of the given assembly, e.g. about the website the assembly has come from, who published it, does it possess a so-called Strong Name or which zone it comes from (Internet, Intranet, Local computer etc.). We can distinguish two types of evidence: Host Evidence and Assembly Evidence. Host evidence is created and provided when the given assembly is loaded by the so-called Host, that is e.g. the shell of Windows (Shell Host), a Web browser (Browser Host) or a Web server (Server Host). Assembly evidence is created and issued by the assembly itself (assuming appropriate functionality has been implemented and included) and by default is ignored - still, it can be used by programmers extending features of security policies provided by the platform.

Role-based security permissions - this permission (there is only one) is granted depending on current identity of the user of the application and the roles (s)he is assigned. Therefore, it makes it possible to restrict, at several levels (the whole assembly, methods, properties etc.), access to selected parts of code depending on the name of currently-authenticated user or the roles this user has been assigned.

Programmers can also create their own, custom permissions in either of the three aforementioned groups

Named Permission Sets

Named permission sets are exactly what their name says - named sets of code access permissions described a moment ago. In addition to the possibility for the administrators to define their own permission sets, the platform provides seven predefined, ready-to-use sets: FullTrust (unrestricted access to all the resources), SkipVerification (permissions to skip verification of code), Execution (execution permissions), Nothing (no permissions), LocalInternet (default permissions granted to applications on a local intranet), Internet (default permissions granted to Internet applications), Everything (unrestricted access to all the resources protected by built-in permissions

Code Groups

Code groups are tree-like structures containing membership conditions, having met which for a certain group results in grant of a permission set assigned to this group. Let us now attempt to resolve this enigmatic definition.

As mentioned earlier on, every loaded assembly gets created so-called Evidence, containing information about origin of that assembly. Afterwards, the CLR initiates the process of evaluating that evidence and, basing on this, granting the assembly appropriate permissions. Code groups are exactly what enables configuration and control of the evidence evaluation process. A single code group contains two very important properties: a membership condition and a permission set. The first property - the membership condition - can be e.g. the condition that an assembly must originate from a certain URL (e.g. "http://www.t3.com.pl") or possess a so-called Strong Name, in further section of this article we will describe other predefined kinds of condition provided together with .NET Framework. A test of meeting a condition takes place by comparing arguments of the condition with elements of the given assembly's evidence. The second property is a permission set - that is, permissions which will be granted if the membership condition is met. Therefore, now we know what a code group is - a definition of a condition of belonging to it and permissions granted when that condition is met. What is then the point of merging such code groups into a tree-like structure? The reason for that is that such hierarchical system of conditions and permissions allows the administrator to perform extremely flexible modelling of the permission-granting process. The root of such a tree is a code group (called "All_Code") whose membership condition is always met by all assemblies. All child code groups can be composed into arbitrary tree-like structures, in which the CLR will verify whether the condition is met for a certain code group assuming the conditions it its parent groups have been met as well. In order to understand better how code groups work, let us have a look at Figure 1.

Figure 1. Security policies - an example code group tree

The code group model presented in the figure tells the CLR that:

• by default we revoke all assemblies all their permissions

• however, if they come from a local intranet we grant them the permission set called "LocalIntranet"

• if they originate from the trusted Web site "http:// t3.com.pl" we grant them "LocalIntranet" permissions too

• moreover, if assemblies originate from the trusted Web site "http://t3.com.pl" and additionally possess a Strong Name, the public key of which matches the value provided as an argument to the condition - we grant it two permission sets: "LocalIntranet" and "Execution"

• if an assembly originates from the trusted Web site "http://t3.com.pl" and displays a publisher certificate of the company (nomen omen) "Software", it will be granted "LocalIntranet" and "FullTrust" permissions

The final permission set is a sum of all the permissions the CLR obtained while traversing the tree. Therefore, if we launched an imaginary application originating from the Web site "http://t3.com.pl" and possessing a Strong Name the public key of which equals the value passed as an argument of the condition, such an application would be granted permissions defined by the permission set "LocalIntranet" along with permission contained in the permission set "Execution".

.NET Framework provides eight predefined membership conditions we can use:

• All code - this condition is met by all assemblies

• Application directory - this condition is met if the assembly in question is located in the same directory as the application or in one of its subdirectories

• Cryptographic hash - this condition is met for assemblies whose MD5 or SHA1 has equals the one passed as an argument to the condition

• Software publisher - this condition is met if the assembly in question is signed with a certificate issued by the publisher specified as an argument to the condition

• Site membership - this condition is met if the assembly in question originates from a defined Web site

• Strong name - this condition is met if the assembly possesses a Strong Name with its public key equal to the one passed to the condition as an argument

• URL - this condition is met if the assembly originates from the URL passed as a condition argument ("*" wildcards are allowed)

• Zone - this condition is met if the assembly originates from the zone passed to the condition as an argument (the following zones exist: Internet, Intranet, MyComputer, NoZone, Trusted, Untrusted).

Additionally, programmers are able to define their own, custom membership conditions - the same applies to permission sets and code groups. Furthermore, their definitions can be written to or read from XML files.

Security Policy Levels

Let us now move on to the most general element of a security policy, namely - to security policy levels.

We distinguish four policy levels:

• Enterprise Policy, stored in the file enterprisesec.config

• Machine Policy, stored in the file security.config

• User Policy, stored in the file security.config in user's personal directory

• Application Domain Policy

Each of these elements (except application domain policy) has its own tree of code groups, list of permission sets, definitions of permissions themselves and of membership conditions. This structure is illustrated by Figure 2.

Figure 2. Three levels of a security policy: Enterprise, Machine, User

Security policy levels make it possible for the administrator to apply different policies of evidence evaluation and permission granting at the level of whole enterprises, individual computers and logged-in users. The process of determining the so-called effective (final) permission for the loaded assembly is therefore slightly more complicated than we described it in the section discussing code groups. Namely - having loaded the assembly the system determines its permissions by processing code groups at the highest (enterprise) policy level, after which the process is repeated at the Machine Policy level and finally at the User Policy level. The final, not always applicable level is the Application Domain, defined by the host which is loading the assembly (to discuss application domains would be beyond the scope of this article - therefore, we'd like to refer the readers to documentation of .NET Framework SDK). The CLR sums permissions granted at each level - staying faithful to the rule that permissions from a higher level can never be elevated at a lower level but can be reduced. This means that if administrators e.g. deny certain applications access to the system registry at the level of the whole enterprise, no assembly will be granted access to that registry even if the permission has been granted at the machine level.

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence