Secure ASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: 1.1

Permission to Trust

Custom ASP.NET Trust Levels

By Don Kiely

In my last column (Play It Safe) I discussed how ASP.NET implements various trust levels. It uses config files to pre-define various levels, ranging from Minimal to Full Trust. There is nothing magic about these levels; a level is simply a pre-defined set of permissions that define what protected resources your application can access, as well as limitations on access that are specific to each type of resource.

The pre-defined trust levels are probably fine for some kinds of intranet applications for which you don t have to worry too much about protecting valuable resources. But because none of them provide an exactly correct set of restricted and unrestricted permissions, you can t use any of the pre-defined levels without leaving open unnecessary security holes. The critical principal of least privilege mandates that you give an application the minimum set of restricted permissions it needs to run, and no more, for the shortest possible time. As hackers become increasingly clever in their attacks, any production application needs to have a well-defined, custom trust level defined and implemented.

Fortunately, this is relatively easy to do, once you have defined the minimum set of permissions your application requires. With that list, the easiest way to get started is to steal one of the pre-defined config files. For the sake of example, I ll start with web_minimaltrust.config, which defines the Minimal Trust Level. Because this level already has close to the minimum permissions necessary for an ASP.NET application, all you have to do is add the new permissions you need. (By the way, you might notice a security.config file in your framework config files. This is the main file used to define the Machine security for .NET code access security. Those settings are relevant to any .NET code that runs on the machine, but is not directly relevant to defining custom ASP.NET trust levels. For the record, however, creating a custom trust level is implementing the AppDomain policy level for an application.)

Copy web_minimaltrust.config and create a new file with a different name, such as MyCustomTrustLevel.config. Open it in the XML or text editor of your choice and begin hacking. Let s say that the only real resource that my application has to access is the e:\weblog directory to read and write custom log files. Start by adding the FileIOPermission to the SecurityClass section:

<SecurityClass Name="FileIOPermission"

 Description="System.Security.Permissions.FileIOPermission,

 mscorlib, Version=1.0.5000.0, Culture=neutral,

 PublicKeyToken=b77a5c561934e089"/>

This defines the .NET Framework class that contains the FileIOPermission class, identifying it through its strong name.

Next, add a restricted file I/O permission to the ASP.NET named permission set. This is the collection of permissions included with the AppDomain used by the Common Language Runtime to determine the actual permissions your ASP.NET assembly has at run time. In this case, we only want the application to be able to access e:\Weblog:

<IPermission class="FileIOPermission" version="1"

 Read="e:\weblog" Write="e:\weblog" Append="e:\weblog"

 PathDiscovery="e:\weblog"/>

Save the file. By convention, put it in the CONFIG directory with the other config files.

Next, you must insert the custom trust level in machine.config. Add a new <trustLevel> element to the securityPolicy section:

<system.web>

 <securityPolicy>

 <trustLevel name="Full" policyFile="internal"/>

 <trustLevel name="High" policyFile="web_hightrust.config"/>

 <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>

 <trustLevel name="Low" policyFile="web_lowtrust.config"/>

 <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>

 <trustLevel name="MyCustom" policyFile="MyCustomTrustLevel.config"/>

 </securityPolicy>

 <!--  level="[Full|High|Medium|Low|Minimal]" -->

 <trust level="Full" originUrl=""/>

</system.web>

Name the trust level any legal XML name; this is how you ll reference the name in your application s web.config file. You can also change the level attribute of the <trust> element to use your custom level by default. If you aren t going to use any of the built-in levels on this machine, feel free to delete those <trustLevel> elements.

Finally, specify your custom trust level for your application in its web.config file:

<system.web>

 <trust level="MyCustom" originUrl=""/>

</system.web>

The most difficult part of defining a custom trust level, besides establishing the permission set your application requires, is deploying the config files. It requires both modifying built-in files (machine.config) and installing new files in the proper location, then hooking your application into the custom level.

Voil ! You have now have taken a big step toward a secure ASP.NET application by locking it down and removing extraneous permissions. You still have a lot of work to do to have a secure application, though, and I ll talk more about that in coming columns.

In the next installment I ll look at the difference between restricted and unrestricted permissions, as well as how to define them for your applications.

Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, AK. E-mail him at mailto:donkiely@computer.org.