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.

Comments

• Anonymous
  May 21, 2009
  PingBack from http://microsoft-sharepoint.simplynetdev.com/security-policy-in-the-v4-clr/

• Anonymous
  May 21, 2009
  How far does this extend? Can an application still create a sandboxed AppDomain (without needing to opt back in to the full managed policy on the primary AppDomain)? Is the Strong Name signature of a referenced assembly that's not located in the GAC still verified by the loader when loaded into a context where the managed security policy is disabled? And finally, is there an MSDN article that describes the change in more detail?

• Anonymous
  May 21, 2009
  Hi Timothy, You can absolutely still create a sandboxed domain - in that aspect you're acting as a bit of a host yourself ... you're creating a sandbox to host untrusted code within.   Instead of using policy to setup that domain however, you should instead use the simple sandbox APIs to do so. Non-GACed assemblies will not have their strong name signautres verified in the default domain of an unhosted application since they will be fully trusted without the use of their signature (http://blogs.msdn.com/shawnfa/archive/2008/05/14/strong-name-bypass.aspx) http://msdn.microsoft.com/en-us/library/dd233103(VS.100).aspx is the best starting point in MSDN for the v4 changes. -Shawn

• Anonymous
  May 21, 2009
  Thank you! I'm glad to hear that this long-standing pain point has finally been resolved.

• Anonymous
  May 21, 2009
  Hi Shawn, picking up Dominick's idea I totally agree with him that it'd be a great idea to convince you to write a book on .NET 4.0 Security. Please think about starting that book project. In the meantime: Thanks for starting this very useful series of articles! -- Tom

• Anonymous
  May 21, 2009
  What means "unhosted applications"?

• Anonymous
  May 21, 2009
  Are there any changes in how CAS applies to XBAP and ClickOnce apps ? I'm thinking specifically of clickonce & xbap apps with Intranet permissions, rather than Internet. When things work ClickOnce deployment is great, but when the dreaded "Trust not granted" pops up, it's a right pain to sort! Admittedly, some of it is a developer education issue re. CAS/caspol.

• Anonymous
  May 22, 2009
  Hi Smith, An unhosted application is basically just a managed .exe that you run directly.  That is, it's not run within a larger host (think ASP.NET, SQL Server, or as an addin in another application for instance). -Shawn

• Anonymous
  May 22, 2009
  Hi Andy, ClickOnce will still evaluate what permissions it thinks is safe for an application to request based upon where the application is coming from.  If the app is requesting more than that safe set, it will continue with its v3.5 behavior of prompting the user to allow the elevation. -Shawn

• Anonymous
  May 22, 2009
  Yesterday I talked about the changes in security policy for managed applications , namely that managed

• Anonymous
  June 09, 2009
  Over the last few posts, I’ve been looking at how the update to the CLR v4 security policy interacts

• Anonymous
  June 12, 2009
  Over the last few weeks we’ve been looking at the changes to security policy in .NET 4, namely that security

• Anonymous
  June 12, 2009
  Over the last few weeks we’ve been taking a look at the updates to the CLR security policy system in