Microsoft KB Archive/815143

From BetaArchive Wiki

Article ID: 815143

Article Last Modified on 7/8/2005



APPLIES TO

  • Microsoft .NET Framework 1.1
  • Microsoft .NET Framework 1.0



SUMMARY

This step-by-step article describes how to audit the security of the Microsoft .NET Framework configuration.

The security of a system decreases as new elements are added to the ideal system configuration. New application installations, software updates, temporary configuration changes, and troubleshooting change aspects of the configuration of a security system. Whether intentional or unintentional, these changes may cause the system to no longer meet security requirements. The .NET Framework is no exception to this issue.

The .NET Framework is designed to permit applications to run on the system in a security-enhanced environment. This environment grants to applications only those rights that the administrator specifically permits. Changes to the configuration of the .NET Framework may cause applications to be granted too many rights. To keep your applications from receiving too many rights, perform regular audits of the system security configuration. Document and then evaluate any changes to the .NET Framework configuration that you introduce to the system. When you must, reverse the changes.

This article describes the key configuration settings that affect the .NET Framework. Document these settings when you first configure your system in the clean state. Perform regular audits to compare the current settings against the original settings. These audits help you to prevent the degradation of system security over time. This article does not describe how to configure these settings.

For additional information about auditing security configuration items that are related to ASP.NET applications, click the following article number to view the article in the Microsoft Knowledge Base:

815144 HOW TO: Audit the Security of an ASP.NET Web Application or Web Service


back to the top

Policy Configuration Files

The .NET Framework uses a hierarchy of files to determine what policy to apply to an application. Each of these policy types can affect the security of the .NET Framework:

  • At the highest level, you can define and then distribute an enterprise security policy throughout an organization. The enterprise policy configuration file is \System Root\Microsoft.NET\Framework\Version\CONFIG\Enterprisesec.config.
  • Computer security policies reside on individual computers. These policies specify configuration items that apply only to that computer. The computer policy configuration file is \System Root\Microsoft.NET\Framework\Version\CONFIG\Security.config.
  • User policies apply to individual users. The user policy configuration file is User Profile\Application data\Microsoft\CLR security config\Version\Security.config.

Include all these security types in your audit, and then monitor each of these files for changes. This way, you can document valid changes and then reverse any changes that are not valid.

back to the top

Policy Levels

In addition to the policy configuration files, several files define the level of authorization that is granted to assemblies that are assigned different trust levels. You can change these files to allow more specific control over the rights that you grant to assemblies. However, be careful to verify that all changes are legitimate. Improper changes to these files can allow an assembly to be granted more rights than you intend. For example, if you copy the Web_hightrust.config file over the Web_notrust.config file, assemblies that must operate with minimal access to the system are granted sufficient permissions to compromise private data.

The details of the configuration of the various trust levels are defined in the following three files. The files are located in the \System Root\Microsoft.NET\Framework\Version\CONFIG\ folder:

  • Web_notrust.config. This file defines the No trust level.
  • Web_lowtrust.config. This file defines the Low trust level.
  • Web_hightrust.config. This file defines the High trust level.

Monitor each of these files for changes so that you can document valid changes and then reverse any changes that are not valid.

Note The Full trust level does not allow customization. The Full trust level also does not have a file that you can change.

back to the top

REFERENCES

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

315736 HOW TO: Secure an ASP.NET Application by Using Windows Security


315588 HOW TO: Secure an ASP.NET Application Using Client-Side Certificates


818014 HOWTO: Secure Applications That Are Built on the .NET Framework


back to the top

Keywords: kbhowtomaster kbvalidation kbsecurity kbconfig KB815143