Gallery

.NET security

Posted on 26 Jul 2006 at 15:16

Thomas Lee looks at the security architecture of .net and delves into code access security

• Enterprise: policy that applies to computers throughout an enterprise and is located at %systemroot%\ Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.

• AppDomain: policy applied to a specific application running on a machine. The AppDomain policy is specified by the application calling the System.AppDomain.SetAppDomainPolicy method.

The three main policy config files are XML based and can be edited by hand, if you're brave enough. Alternatively, you can use either the caspol.exe command-line tool or the mscorcfg.msc MMC snap-in tool.

To use mscorcfg.msc to set policy, you first create your code groups representing the different groups of assemblies to which you're planning to apply different permissions. These can be nested and you can have as many as you need (although moderation is probably a good thing here). In the screenshot above, you can see a Code Group for PC Pro Generated Code, and in the screenshot on p169 a sub-group Special PC Pro Code. The tool allows you to specify the membership conditions, as shown in the screenshot above. You might identify the code based on an X.509 Certificate used to sign relevant assemblies. The sub-group, Special PC Pro Code, is a subset of code that meets the parent condition but requires some additional evidence (for example, a hash for a particular assembly) to which different permissions could be applied. This allows you to group all PC Pro code into one group, with certain special assemblies in the child group.

Once you've defined your code groups, you need to define the permission sets that are to be applied to them. A permission set is a list of detailed permissions that can be applied to a particular assembly. Permission sets control access to a large variety of objects on the computer, including:

Directory services Reflection

DNSSecurity

Event logService controller

Environment variablesSocket access

File dialogSQL client

Isolated storageWeb access

Message queueUser interface

Performance countersX509 store

Printing

Any object on your computer that malware could exploit is protected, down to very detailed levels. In the example shown in the screenshot on p169, you might apply general permissions to the main code group. All PC Pro code might be trusted to open files with r/w permission in the C:\PCPRO folder, and might be permitted to print and write to the Event log. The Special PC Pro assemblies, in the child code group, might get additional permissions, such as the ability to read or write to certain parts of the Registry, or to read and/or write to some part of Active Directory. Once you complete the creation of permission sets, you can apply a permission set to each of the code groups defined earlier.

Policy enforcement

Policy is enforced both implicitly and explicitly. The CLR itself enforces policy implicitly. If an assembly tries to access a file for which it doesn't have a permission set, the operation will fail. Developers can set attributes in code that declare what security is needed, and this can be checked at runtime. In addition, security checking can be imperative - a subordinate assembly can force .NET to perform a stack-walk, whose purpose is to ensure all callers in the chain so far had some appropriate permission.

Let's take a look at how this works. First, suppose we have an application called myapp.exe installed on the local hard drive. This application, among other things, clears a log file by calling an external assembly, as follows: