.NET Framework Security

The .NET Framework default security policy is the culmination of the default policies of all four policy levels. Each policy level has a hard-coded default that is intended to provide a usable and secure environment.

All of the default policy levels are identical with reference to the permission set lists and assembly lists. The permission set lists contain all the named permission sets described earlier in the chapter and no other permission sets. The assembly lists contain the following assemblies:

• mscorlib.resources

• System.dll

• System.resources

• System.Data.dll

• System.Data.resources

• System.Drawing.dll

• System.Drawing.resources

• System.Messaging.dll

• System.Messaging.resources

• System.ServiceProcess.dll

• System.ServiceProcess.resources

• System.DirectoryServices.dll

• System.DirectoryServices.resources

In addition, mscorlib.dll is always considered a fully trusted policy assembly, even though it is not in the list.

With regard to the code group hierarchy, the Enterprise and User default policy levels are simple and identical. The Machine policy level has a larger, more complex hierarchy that really does the work of making default policy "locked down." There is no default AppDomain policy level. If it isn't set by an application, it doesn't exist.

Enterprise and User Policy

The code group hierarchies of these two policy levels contain a single node ” the root code group. This root code group is a UnionCodeGroup with an AllMembershipCondition and the FullTrust permission set. Hence, all code matches the root code group and is granted all permissions that implement the IUnrestricted interface.

The most important point to understand with these policy levels is that when their grant sets are intersected with some permission set P, the result is P (minus any identity permissions). That is why only one of the four policy levels needs to have a more complex default. Anything restricted in that policy level will define the total default restrictions.

Machine Policy

The machine policy's code group hierarchy is primarily based on the IE security zone model. Figure 8.4 shows a graphical representation of the machine policy level's code group hierarchy. No code groups in default security policy have any PolicyStatementAttribute s. Remember that these are the defaults for SP1. The default code group hierarchy of the original release is different.

The root of the code group matches all code, but grants no permissions. Below that lies a code group for every security zone. All executing code falls into only one zone, and is thus given that zone's permissions. The following is some rationale behind the decisions made in constructing the default machine code group hierarchy:

• Users have to take action to copy or install code onto their machines, so that code can be granted full trust.

• Code from an Internet site deemed "trusted" needs to be able to display basic UI, store state data, print, open files that the user specifies, and connect back (via the network) to the same site where the code originated.

• Code from your intranet should be able to do everything code from a trusted site can do. In addition, it should be able to get DNS information from the network, use the event log, have unlimited UI capabilities, emit new assemblies, read some environment variables , and read any files in the directory where the executing assembly originated.

• Code can only end up in the untrusted zone by an explicit action from an end user or administrator, so that code should not be granted any permissions.

• It isn't clear how many permissions should be given to code in the Internet zone. In order to provide "locked down" default behavior, no trust is given to that code (which prevents execution). However, many users will probably want to grant some permissions to Internet code. The "Internet" permission set provides a good example of what permissions to consider granting.

• Any system code on the local machine should be given full trust. System code is designated by the use of strong names on assemblies, which is discussed in Chapter 9, "Understanding the Concepts of Strong Naming Assemblies." Special code groups are provided for system code so that they are still given full trust if the MyComputer zone code group is locked down.