Increasing Permissions

Depending on how it is authored, a managed application that requires more permission to run than the current policy allows will throw an exception, fail to execute, or not function properly. You can use the Permissions View tool (Permview.exe) to view the minimum permissions requested, optional permissions requested, and permissions refused by assembly to compare the permissions that the assembly requests to the permissions that it actually receives. Note that this tool only shows permissions that have been explicitly requested by the application using declarative syntax. With this information, you can increase the permissions that the assembly receives by creating a new custom code group and associate it with a new custom permission set that contains all the permissions that the application needs to run properly. However, you should increase the permissions only if you trust the application's source and you should only trust according to evidence that is suitably reliable. (In most cases, administrators will have several custom code groups that can be used to categorize several applications requiring similar permissions.)

Suppose you have an application that is frequently accessed by several users from a network share. In an unmanaged context, this situation does not usually pose an execution problem. However, in a managed context, this application might be granted a limited set of permissions because it originates from the local intranet zone. For example, the application might not be allowed full printing permissions, which limits this application's usefulness. Rather than loosening the settings for the entire local intranet zone, you should do the following:

  1. Use the Permission View tool (Permview.exe) to view the minimum permissions requested by the assembly whose permissions you want to increase. These are the permissions the application minimally needs in order to run.

  2. Identify a unique characteristic of the assembly. This characteristic could include the assembly's strong name, its public key, its hash, or a unique custom attribute. If the application originates from a trusted server, the location can also be used to identify the application. Remember, you trust all code that has this characteristic.

  3. Create a new code group that requires the unique identifier for membership. Use the .NET Framework Configuration tool(Mscorcfg.msc) or the Code Access Security Policy tool (Caspol.exe) to create the code group.

  4. Create a new permission set that includes all the permissions the assembly minimally needs in order to run by using the .NET Framework Configuration tool or the Code Access Security Policy tool.

  5. Associate the new permission set with the new code group by using the .NET Framework Configuration tool or the Code Access Security Policy tool.

After you have completed these steps, the application will run and receive sufficient permissions to function. Other, less trusted applications will not receive the extra permissions; this helps protect your system against malicious code. For information on performing specific tasks using the security tools, see Security Policy Configuration.

See Also

Other Resources

General Security Policy Administration

Security Policy Best Practices