codegeeks

Home > Tips, links, vb.net > Security Policy in the v4 CLR

Security Policy in the v4 CLR

May 23rd, 2009

One of the first changes that you might see to security in the v4 CLR is that we’ve overhauled the security policy system. In previous releases of the .NET Framework, CAS policy applied to all assemblies loaded into an application (except for in simple sandbox domains).

That lead to a lot of interesting problems. For instance, one of the more common issues people ran into was that they would develop an application on their local machine that they wanted to share with other people on the network. Once the application was working on their machine, they would share it out, but nobody could run it over the network because CAS policy provided a lower grant set to assemblies loaded from the intranet than it does to assemblies loaded from the local machine. The usual result was unexpected and unhandled SecurityExceptions when trying to use the application.

Generally, the only solution to this problem was to either manually update the CAS policy on each machine that wanted to run the application, deploy the application some other way (for instance via ClickOnce), or use native code.

One of the worst things about this problem was that the additional pain of not being able to just share a managed app over the network wasn’t actually buying any security. If an application wanted to attack your machine, it could bypass the sandbox that the CLR was setting up simply by being written in native code.

Read the rest.