Using Libraries from Partially Trusted Code
This topic addresses the behavior of strong-named assemblies and applies only to Level 1 assemblies. Security-Transparent Code, Level 2 assemblies in the .NET Framework 4 or later are not affected by strong names. For more information about changes to the security system, see Security Changes in the .NET Framework.
Code Access Security and Partially Trusted Code
The .NET Framework provides a mechanism for the enforcement of varying levels of trust on different code running in the same application called Code Access Security (CAS). Code Access Security in .NET Framework should not be used as a security boundary with partially trusted code, especially code of unknown origin. We advise against loading and executing code of unknown origins without putting alternative security measures in place.
This policy applies to all versions of .NET Framework, but does not apply to the .NET Framework included in Silverlight.
Applications that receive less than full trust from their host or sandbox are not allowed to call shared managed libraries unless the library writer specifically allows them to through the use of the AllowPartiallyTrustedCallersAttribute attribute. Therefore, application writers must be aware that some libraries will not be available to them from a partially trusted context. By default, all code that executes in a partial-trust sandbox and is not in the list of full-trust assemblies is partially trusted. If you do not expect your code to be executed from a partially trusted context or to be called by partially trusted code, you do not have to be concerned about the information in this section. However, if you write code that must interact with partially trusted code or operate from a partially trusted context, you should consider the following factors:
Libraries must be signed with a strong name in order to be shared by multiple applications. Strong names allow your code to be placed in the global assembly cache or added to the full-trust list of a sandboxing AppDomain, and allow consumers to verify that a particular piece of mobile code actually originates from you.
If a caller does not have full trust but still tries to call such a library, the runtime throws a SecurityException and the caller is not allowed to link to the library.
In order to disable the automatic LinkDemand and prevent the exception from being thrown, you can place the AllowPartiallyTrustedCallersAttribute attribute on the assembly scope of a shared library. This attribute allows your libraries to be called from partially trusted managed code.
Partially trusted code that is granted access to a library with this attribute is still subject to further restrictions defined by the AppDomain.
There is no programmatic way for partially trusted code to call a library that does not have the AllowPartiallyTrustedCallersAttribute attribute.
Libraries that are private to a specific application do not require a strong name or the AllowPartiallyTrustedCallersAttribute attribute and cannot be referenced by potentially malicious code outside the application. Such code is protected against intentional or unintentional misuse by partially trusted mobile code without the developer having to do anything extra.
You should consider explicitly enabling use by partially trusted code for the following types of code:
Code that has been diligently tested for security vulnerabilities and is in compliance with the guidelines described in Secure Coding Guidelines.
Strong-named code libraries that are specifically written for partially trusted scenarios.
Any components (whether partially or fully trusted) signed with a strong name that will be called by code that is downloaded from the Internet.
Some classes in the .NET Framework class library do not have the AllowPartiallyTrustedCallersAttribute attribute and cannot be called by partially trusted code.