Security Policy in the v4 CLR
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.
Effectively, running an executable is a trust decision – you’re saying that you trust the application that you’re running enough to execute with the privileges your Windows account has.
That leads to an interesting observation – the CLR isn’t the correct place to be setting permission restrictions for applications that are being launched directly (either from the command prompt, or from Windows explorer for instance). Instead, that should be done through Windows itself using mechanisms like SRP, which apply equally to both managed and native applications.
In the v3.5 SP1 release, these observations (writing managed code to use on the network was harder than it needed to be, and it wasn’t even buying any extra security) led us to relax CAS policy for LocalIntranet applications slightly. We enabled applications that were run directly from an intranet share (and any assemblies loaded from immediately next to that application) to be fully trusted by pretending that it had MyComputer zone evidence instead of LocalIntranet.
In the v4.0 release of the runtime, the CLR has taken that a step further. By default, unhosted applications are not subject to managed security policy when run under v4.0. Effectively, this means any managed application that you launch from the command prompt or by double clicking the .exe in Windows Explorer will run fully trusted, as will all of the assemblies that it loads (including assemblies that it loads from a location other than the the directory where the executable lives).
For applications run from the local machine, there really should be no observable change. However, for applications that are shared out over a network, this means that everything should just work – just as if you had run the application from your computer while you were developing it.
One very important point about this change is that it specifically applies only to unhosted code. In my next post, we’ll look at what v4.0 security policy means for CLR hosts.