Security Changes in the .NET Framework 4

         There have been two major changes to security in the .NET Framework version 4. Machine-wide security policy has been eliminated, although the permissions system remains in place, and security transparency has become the default enforcement mechanism. In addition, some permission operations that presented the potential for security vulnerabilities have been made obsolete.

Important

Code access security (CAS) has not been eliminated, Security policy has been eliminated from CAS, but evidence and permissions are still in effect. A few permissions have been eliminated, and transparency has simplified the enforcement of security.

We should be aware of the following key points:

• Transparency separates code that runs as part of the application from code that runs as part of the infrastructure. It was introduced in .NET Framework version 2.0, and has been enhanced to become the code access security enforcement mechanism. Unlike security policy, level 2 transparency rules are enforced at run time, not at assembly load time. These rules are always in effect, even for assemblies that run as fully trusted by default. However, level 2 transparency does not affect fully trusted code that is not annotated, such as desktop applications. Assemblies (including desktop assemblies) that are marked with the SecurityTransparentAttribute and that call methods marked with the SecurityCriticalAttribute receive a MethodAccessException. You can change this behavior by applying the SecurityRulesAttribute and setting the SecurityRulesAttributeRuleSet property to Level1; however, you should do this only for backwards compatibility. You must explicitly mark a desktop application as security-transparent to apply transparency restrictions to it.
• Code that calls security policy APIs receives a NotSupportedException in addition to compiler warnings at run time. Policy may be re-enabled by using the configuration element. When policy is enabled, security transparency is still in effect. Security policy is applied at assembly load time and has no effect on transparency, which is enforced by the runtime.
• The obsolete request permissions (RequestMinimum, RequestOptional, and RequestRefuse) receive compiler warnings and do not work in the .NET Framework 4, but they do not cause an exception to be thrown. Deny requests cause a NotSupportedException to be thrown at run time.
• The LinkDemand security action is not obsolete, but it should not be used for verifying permissions. Instead, use the SecurityCriticalAttribute for types and methods that require full trust, or use the Demand method for types and methods that require individual permissions.
• If your application is built with Visual Studio 2010, you can run it without these changes by specifying a target .NET Framework version that is earlier than the .NET Framework 4 in the Visual Studio project settings. However, you will not be able to use new .NET Framework 4 types and members. You can also specify an earlier version of the .NET Framework by using the element in the startup settings schema in your application configuration file.
  
  
  For more things move to the msdn site ...
  http://msdn.microsoft.com/en-us/library/dd233103.aspx