The Default Security Policy

We're now going to examine the default security policy that ships with .NET to get a better idea of the typical CLR security setup.

Code Groups

The easiest way to get a feel for the different code groups is to look at them using the .NET Framework Configuration Tool, mscorcfg.msc. This screenshot shows the default situation for machine policy for a clean install of .NET 1.0:

It's important to stress that this screenshot and subsequent discussion is based on the default code groups in the machine configuration that you get on installing .NET 1.0 SP2 - and so won't necessarily apply if you've already been fiddling with your security policy. You can modify, add or delete code groups to suit whatever security policy you want on your system - and you also should not expect that future versions of .NET will come with exactly the same default settings.

mscorcfg shows that the code groups form a tree structure, with the All_Code group at the top of the tree. It's worth a couple of words of explanation of the main groups.

My_Computer_Zone indicates any code that is stored on the local computer, while LocalIntranet_Zone indicates any assembly that is located on a shared network folder. Between them these zones cover any assembly that is accessed as a file on the local network. In the case of My_Computer_Zone, there are additional code groups that indicate code that has been signed by either the Microsoft or the Microsoft/ECMA strong names. Recall from Chapter 4 that those assemblies such as mscorlib.dll and system.dll that contain classes defined by the ECMA standard are signed by the Microsoft/ECMA strong name, while the remaining classes supplied by Microsoft are signed with the Microsoft strong name.

Of course, with .NET, code can also be executed by someone typing in the path to the code (or to a web page that contains an <object> tag that invokes the assembly) in Internet Explorer. The remaining code groups between them cover this possibility, as well as any code that has been programmatically loaded with a URL as the path. Downloaded code is divided into three groups: Internet_Zone, Restricted_Zone, and Trusted_Zone. What counts as trusted or as restricted is not under the control of the CLR - that is an Internet Explorer setting. If you want to add a site to either the trusted or the restricted zones then you will find the appropriate menu option in the Security tab of the Internet Options dialog in Internet Explorer.

Remember that an assembly is not restricted to any single code group - it might satisfy the membership condition for several groups. When checking which code groups an assembly is a member of, the CLR will work recursively down the hierarchy of code groups. However, if a particular assembly does not satisfy the membership condition for some group, the CLR will not examine child groups. For example, code that has been downloaded from the Internet does not satisfy the condition for My_Computer_Zone. Therefore the CLR will not check whether this code satisfies the Microsoft_Strong_Name or ECMA_Strong_Name child groups. Because these groups are children of the My_Computer_Zone group, only code that falls into My_Computer_Zone too is allowed to be a member of these groups.

Permission Sets

A permission set is simply a set of permissions. Again, it's possible to see the default ones using the MMC snap-in:

Unlike the code groups, most of these default permissions are fixed by Microsoft and cannot be edited. Of the default permission sets, the only one which can be modified is the Everything group, though you can freely create new permission sets if for some reason the default ones don't match up to your needs. The reason for fixing these permission sets is that Microsoft believes them to represent typical and intrinsically useful sets that should therefore always be available. The following table indicates the rough purpose of the sets, and indicates which code groups use them by default (as of .NET 1.0 SP 2). Notice that not all the permission sets are actually used; some of them have simply been defined in case you want to use them:

Permission Set	Code Groups that by Default Use this Set	Description
FullTrust	My_Computer_Zone	Code with this permission set is completely trusted - the CLR imposes no CAS-based restrictions on what this code does.
	ECMA_Strong_Name
	Microsoft_Strong_Name
SkipVerification		Allows code to execute even if it is not verifiably type-safe.
Execution		Allows code to execute.
Nothing	Internet_Zone Restricted_Zone	This set does not contain any permissions whatsoever. Code that has this permission set will not be allowed to execute.
Internet	Trusted_Zone	Gives a highly restricted set of permissions, allowing code to create top-level windows, present a file dialog and use isolated storage, but not much more than that.
LocalIntranet	Local_Intranet_Zone	Gives a restricted set of permissions appropriate to intranet code. This includes Internet permissions plus a couple of others, including the ability to use the DNS service and the Reflection.Emit classes.
Everything		Virtually all Microsoft-defined permissions are assigned, so code can do almost anything covered by these permissions. The exception is the security permission, SkipVerify.

The Internet Zone

It's not hard to see the reasoning behind most of the allocations of permissions to code groups in the above table, though you may be surprised that Internet_Zone code does not have any permission - which means that on the default policy you cannot execute such code. In the long term, Microsoft's intention appears to be that Internet_Zone code should have Internet permission, which will allow you to run code from the Internet while guaranteeing that such code cannot damage the integrity of your system, or read your files, and when .NET 1.0 was originally released, this was the default policy. However, later service packs amended the policy to give this code no permissions. The precise reason for this change was never documented, though it appears that Microsoft had decided to be extra-careful with its default security policy until the framework had matured somewhat in the field, since early reports suggest that in .NET 1.1 the default policy will revert back to giving Internet_Zone code the Internet permission set.

Fully and Partially Trusted Code

One point that does confuse developers on occasions is why there is a permission set called FullTrust as well as a set called Everything. Don't the two amount to the same thing? The answer is no: FullTrust is a very special permission set, which conceptually indicates to the CLR that this code is completely trusted. The CLR will always grant fully trusted code any permission that the code asks for. The FullTrust permission set doesn't even contain a list of permissions to check against - there's no point, since the granting of any permission is automatic. If some code is identified as having any permission set other than FullTrust, then that code is conceptually regarded as partially trusted - in other words, that code has been given a set of permissions, and will be permitted to perform all the operations granted by those permissions, but is nevertheless inherently viewed with suspicion. The Everything permission set happens to include virtually all the permissions that have been defined by Microsoft - hence its name; however, any code running under the Everything permission set is still regarded as partially trusted. This is significant because there are a couple of things that the CLR will never allow partially trusted code to do, no matter what permissions that code has:

• Directly invoke an assembly that has been signed with a strong name, unless the strongly named assembly has specifically indicated it is happy to be called by partially trusted callers (it can do this by defining an assembly-level attribute, AllowPartiallyTrustedCallersAttribute).

• Register custom security permissions.

Another distinction between FullTrust and Everything becomes evident if you register your own custom permissions. Any code running under FullTrust will of course automatically be granted those custom permissions if it asks for them. On the other hand, these permissions will not be granted to code running under Everything, unless you explicitly modify the Everything set to include your own permissions. This is the reason why Everything is the one default permission set which you are allowed to modify if you wish: in case you want to add custom permissions to it. Don't be fooled by the name Everything: in reality, this is a permission set just like any other. Microsoft has defined the Everything set in case you ever want some code group to have pretty well all the predefined permissions, but without that code being formally regarded as fully trusted.

Calling Strong-Named Assemblies

There is one extra security requirement that you will have to deal with if you have any strongly named assemblies. As an added security precaution, by default only fully trusted code can invoke methods in strongly named assemblies. The reason for this restriction is that assemblies are normally strongly named in order that they can be widely used by different applications, for example by being placed in the Assembly Cache. Because such assemblies are more widely available, Microsoft decided that the risk is too great that these assemblies might be invoked by malicious code. Hence, if you do sign an assembly with a strong name, it is up to you to make a positive decision that it is OK for partially trusted code to use that assembly. This will normally imply that you feel you have tested the assembly sufficiently that you are satisfied it cannot compromise the integrity of your system, no matter what methods are called in it or what parameters supplied. If you are happy for that to happen, you need to mark the assembly with the AllowPartiallyTrustedCallersAttribute attribute:

 [assembly: AllowPartiallyTrustedCallersAttribute()] 

At the time of writing this attribute has not yet been documented in MSDN. However, you can find details at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/v1securitychanges.asp. It takes no parameters and is defined in mscorlib.dll, in the System.Security namespace.

Of course, it might occur to you that there are a lot of shared assemblies in the framework class library that you use all the time in your .NET programming. Does this mean that these assemblies can only be called from trusted code? Well, to some extent. Microsoft has identified certain assemblies as being OK to be called from partially trusted code. According to the documentation, the list is as follows:

• mscorlib.dll

• System.dll

• System.Windows.Forms.dll

• System.Drawing.dll

• IEExecRemote.dll

• Accessibility.dll

• Microsoft.VisualBasic.dll

• System.XML.dll

• System.Web.Services.dll

• System.Data.dll

The good news (good, if you are writing partially trusted code, that is) is that all the core functionality of the framework (mscorlib.dll and System.dll) is there, and partially trusted code can also access the Windows forms and drawing features, so you can still get a decent user interface. However, you will notice that some key assemblies are missing, including these ones:

• System.Web.dll

• System.Management.dll

• System.DirectoryServices.dll

• System.ServiceProcess.dll

• System.EnterpriseServices.dll

These assemblies have all been deemed to contain code that is simply potentially too dangerous to allow access to clients that are not fully trusted, and in most cases you can probably see the reason why - for example, given how powerful WMI is, you probably don't want partially trusted code playing with the management instrumentation classes. Imagine some malicious code running under an administrator account using WMI - the damage such code could wreak on your system doesn't bear thinking about. The same holds for accessing Active Directory with the System.DirectoryServices classes. System.Web.dll is excluded from the list of libraries that can be called by partially trusted callers because Microsoft feels that if code is partially trusted then it is probably not suitable for use as a web application - presumably because web applications can be so extensively invoked by so many clients.

Bear in mind, however, that the restriction on partially trusted callers only applies to the immediate calling assembly, not to assemblies further up the call stack. This means that it is possible for partially trusted code to access a strongly named assembly, provided it does so indirectly, via an intermediate assembly that is fully trusted, but either has no strong name or (more likely) has the AllowPartiallyTrustedCallers attribute set: