Dangerous Permissions and Policy Administration
Caution
Code Access Security (CAS) 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).
CAS is not supported in .NET Core, .NET 5, or later versions. CAS is not supported by versions of C# later than 7.0.
CAS in .NET Framework should not be used as a mechanism for enforcing security boundaries based on code origination or other identity aspects. CAS and Security-Transparent Code are not supported 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. .NET Framework will not issue security patches for any elevation-of-privilege exploits that might be discovered against the CAS sandbox.
This policy applies to all versions of .NET Framework, but does not apply to the .NET Framework included in Silverlight.
Several of the protected operations for which the .NET Framework provides permissions can potentially allow the security system to be circumvented. These dangerous permissions should be given only to trustworthy code, and then only as necessary. There is usually no defense against malicious code if it is granted these permissions.
Note
In the .NET Framework 4, there have been important changes to the .NET Framework security model and terminology. For more information about these changes, see Security Changes.
The dangerous permissions are explained in the following table.
| Permission | Potential risk |
|---|---|
| SecurityPermission | |
| UnmanagedCode | Allows managed code to call into unmanaged code, which is often dangerous. |
| SkipVerification | Without verification, the code can do anything. |
| ControlEvidence | Invalidated evidence can fool security policy. |
| ControlPolicy | The ability to modify security policy can disable security. |
| SerializationFormatter | The use of serialization can circumvent accessibility mechanisms. For details, see Security and Serialization. |
| ControlPrincipal | The ability to set the current principal can trick role-based security. |
| ControlThread | Manipulation of threads is dangerous because of the security state associated with threads. |
| ReflectionPermission | |
| MemberAccessException | Can use private members to defeat accessibility mechanisms. |