FullTrust on the LocalIntranet

  • Article

We released the first beta of .NET 3.5 SP 1 this morning, and it includes a change to the default grant set for applications launched from the LocalIntranet zone.  The quick summary is that as of .NET 3.5 SP1, applications run from a network share will receive a grant set of FullTrust by default, making them act the same as if they were launched off of your computer directly.  Since this is an issue that I know a lot of people run into, I hope that this change makes it easier to use and deploy managed applications.  For people who want to keep their machines working the same as they did for previous .NET Framework releases, you can set the DWORD registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key.

With the high-level summary out of the way, let's take a look under the hood to see what changed to make this possible :-)

The core of this change is a modification in how we assign evidence to network launched applications.  When we see an .exe launched directly off a network share, rather than giving that .exe Zone evidence of LocalInranet, we instead give the .exe Zone evidence of MyComputer.  This causes the .exe to match the default MyComputer code group rather than the LocalIntranet group, and in default CAS policy that code group grants FullTrust.   (This also explains why the opt-out registry value is named LegacyMyComputerZone)

In addition to the entry point .exe of the application, we'll also extend this MyComputer evidence to any assembly loaded from the same directory as the .exe.  So, if you place any managed .dll's immediately next to your .exe, those will also all be given FullTrust by default in .NET 3.5 SP1.

Since we're only including assemblies loaded from the same directory as the entry point application, things will just work for most applications, however more complicated programs that need to load assemblies from different subdirectories or other network shares may not see all of their assemblies get fully trusted by default.  For these more types of applications, ClickOnce deployment is the recommended way to elevate to FullTrust.

We've specifically disabled this change for any hosted applications.  So this means that if your program uses the CorBindToRuntime API to host the CLR, we won't start trusting assemblies it loads from a share.  Similarly, hosts like Internet Explorer will not start trusting controls that it loads into the browser.

To summarize the under the hood changes, assemblies which will now receive Zone evidence of MyComputer and therefore be fully trusted by default are:

  1. Any managed .exe which is launched directly from a network share
  2. Any assembly in that .exe's process which is loaded from the same directory as the .exe itself was.

Assemblies which will not see this change include:

  1. Assemblies loaded from a subdirectory of the share where the .exe was launched from
  2. Assemblies loaded from shares other than the one where the main .exe was launched
  3. Any assembly loaded on a machine with the LegacyMyComputer registry value set to 1
  4. Any assembly loaded into a CLR host, including assemblies loaded into Internet Explorer as controls.
  5. Any assembly loaded from shares by an application that was launched from the "real" MyComputer zone.

Comments

  • Anonymous
    February 15, 2009
    This change WAS acceptable if you simply added the evidence of MyComputer to the network launced appliications by setting registry key: say, something like "ExpandMyComputerZone" to 1. How come can't you imagine that changing default behaviour of run-time causes huge problems? It looks like all of sudden you began to follow any demand of republicans and don't give an inch against GOP.

  • Anonymous
    February 23, 2009
    The comment has been removed

  • Anonymous
    February 25, 2009
    Hi, Shawn: How about this scenario. entry.exe is a managed code on \root program1.exe is in subfolder \rootsubfolder entry.exe launches program1.exe by using Process.Start(). According to the blog post that for 3.5 SP1, entry.exe has fulltrust, how about program1.exe lauched by entry.exe? Thanks, Michael

  • Anonymous
    February 27, 2009
    Process.Start is going to kick off a new process, where the full trust root is in \rootsubfolder.  In the second process, Entry.exe is not trusted, in the first process Program1.exe is not trusted, but they are each fully trusted in their own processes. -Shawn

  • Anonymous
    March 02, 2009
    you could have also included the "Assemblies loaded from a subdirectory of the share where the .exe was launched from" because, now we'll have to do separate settings for following scenerio. <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" > <probing privatePath="bin;utils"   />    </assemblyBinding>

  • Anonymous
    March 04, 2009
    So happy to find a solution. But wondering what have to be done:

  • rebuild my program in Visual Studio 2008 ?
  • just install 3.5SP1 on the client ? I did first think that it was done by re-building (after converting from VS2005 to VS2008). But I found that VS2008 still only uses Framework 2 in references... and not I am confused...

  • Anonymous
    March 07, 2009
    You only have to install v3.5 SP1 on the client.  No need to rebuild your application. -Shawn

  • Anonymous
    March 17, 2009
    I think the .NET Framework configuration tool needs updating.  If I evaluate an assembly, it still shows permissions as coming from the local intranet. Before I found this post I couldn't understand why my machine always worked regardless of CAS settings while others didn't.  Now it makes sense.

  • Anonymous
    April 21, 2009
    Hi, this change caught me out today (in a good way) when running a small application. I'm curious why "Assemblies loaded from a subdirectory of the share where the .exe was launched from" also do not have full trust? Could you spare a little time to expand on the reasons for this? I'd appreciate it.

  • Anonymous
    May 18, 2009
    Is .net 3.5 is worth its price or it is not worth paying for it.

  • Anonymous
    May 21, 2009
    One of the first changes that you might see to security in the v4 CLR is that we’ve overhauled the security

  • Anonymous
    May 21, 2009
    Hi Derek, >I'm curious why "Assemblies loaded from a subdirectory of the share where the .exe was launched from" also do not have full trust? The reason is that this was a service pack release, and we wanted to make the smallest scoped change that still enables the majority of applications to take advantage of it. As you'll see in .NET 4.0 beta 1, we've significantly expanded this exemption, and now all assemblies loaded by unhosted applications are fully trusted by default. -Shawn

  • Anonymous
    May 21, 2009
    > I think the .NET Framework configuration tool needs updating.  If I evaluate an assembly, it still shows permissions as coming from the local intranet. This is a side-effect of the fact that this feature only applies to the entry point of an applications and assemblies loaded from directly next to that entry point. Since your app won't be loaded from next to the framework evaluation tool, it will look to that process as if the assembly is loaded from the intranet rather than the local machine. -Shawn

  • Anonymous
    January 19, 2010
    I am getting the above exception while running an assembly on LocalIntranet Zone with Win7 x64 (ie .NET 3.5 SP1).  Running locally works fine. To reproduce: Create a console app with the following code in Main: try {  var proxy = System.Net.WebRequest.DefaultWebProxy;  Console.WriteLine("Success"); } catch (Exception ex) {  Console.WriteLine("Failed: " + Environment.NewLine + ex.ToString()); } Console.ReadLine(); And make your App.config like so: <configuration>  <system.net>    <defaultProxy>      <proxy autoDetect="true" />    </defaultProxy>  </system.net> </configuration> If I grant the LocalIntranet_Zone FullTrust in security.config the assembly works fine on Local Intranet. But why should I have to grant this when 3.5 SP1 supposedly does so automatically? The Evidence when run on LocalIntranet shows the Zone as MyComputer so it all looks correct to me except for the behavior!

  • Anonymous
    February 24, 2010
    The comment has been removed

  • Anonymous
    March 19, 2010
    The comment has been removed

  • Anonymous
    March 21, 2010
    The comment has been removed

  • Anonymous
    November 27, 2011
    Hope someone is getting a "ping" although this is an old blog... We are seeing a problem in .Net 4, we were expecting the same behavior as in 3.5 SP1 with regards to which Zone an application "belongs" to when that application is launched from a share within our local network. As the blog states we should be in the zone "MyComputer" (from what we have read this is true for .Net 4 as well) BUT when we print out the zone it turns out we are instead only "Trusted". This causes a problem for us when we later do a simple web-request to a web-page as we have set a parameter in app.config, under system.net (in section defaultProxy) we set the attribute useDefaultCredentials=true. From what we understand the application is not allowed to set this because we are only "Trusted" (we get an exception). From what we have read so far this seems to be a BUG in .Net 4? Can anybody confirm this behavior in .Net 4 or explain why we are only trusted.