FullTrust on the LocalIntranet


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 (18)

  1. Subli says:

    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.

  2. There are two important things to note about this change:

     1. It will not cause existing code to fail.  That is, code that used to fail with a SecurityException will now execute, however code that used to execute will not start failing now.

     2. Code that was sandboxed previously was not actually any more secure — there was a false sense of security there.

    For point #2, running an application is in and of itself a trust decision.  If you do not trust the applicationn, but run it hoping that it is all managed code and therefore sandboxed by being on the network, you’ve already lost.  The reason is, I could have had my application be native code and therefore not subject to managed security policy.

    Note that this specifically does not affect hosted applications, where you trust the host but not the managed assemblies.

    -Shawn

  3. Michael says:

    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

  4. 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

  5. amish says:

    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>

  6. Sune Scherfig says:

    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…

  7. You only have to install v3.5 SP1 on the client.  No need to rebuild your application.

    -Shawn

  8. Steve says:

    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.

  9. Derek Smyth says:

    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.

  10. Is .net 3.5 is worth its price or it is not worth paying for it.

  11. One of the first changes that you might see to security in the v4 CLR is that we’ve overhauled the security

  12. 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

  13. > 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

  14. Pennidren says:

    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!

  15. Hi Pennidren,

    The reason this is happening is that there’s a disconnect about where the restricted permission set is coming from.  The .NET 3.5 SP1 feature is implemented deep in the guts of the CLR, and modifies the evidence of assemblies as they load.

    However, this exception is occuring due to the security system of System.Configuration.  At the System.Configuration level, they’re building their own evidence and then performing a PermitOnly operation on it.  Since that API set built the evidence itself, it didn’t benefit from the CLR VM change and doesn’t reflect the udpate to MyComputer evidence for this application.

    Thankfully this will all be resolved in .NET 4, where no Evidence games are required for unhosted applications to be fully trusted out of the box.

    -Shawn

  16. James says:

    Hi,

    I have installed .net 3.5 SP1 on my local machine, but when I locate the site on the shared hosting I am using I get this error:

    " System.Security.SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed."

    I am trying to play a sound file on the server using :

    Dim mvda as New Microsoft.VisualBasic.Devices.Audio()

    as

    mvda.Play(path, Microsoft.VisualBasic.AudioPlayMode.Background)

    Why is this error happening?

    The hosting server is set for Medium trust level.

    Is there any way I can avoid this without changing my local set-up?

    Or, how can I correct this by changing my local setup?

    When I set my local system to Medium trust, my MySql data connections don’t work, and I can see I am going to go down a deep rabbit hole in trying to fix this from my side.

    I am using VWD 2008, so the option to publish my site using it as you can with VS is not available.

    Thanks in advance.

  17. James says:

    Hi,

    I have installed .net 3.5 SP1 on my local machine, but when I locate the site on the shared hosting I am using I get this error:

    " System.Security.SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed."

    I am trying to play a sound file on the server using :

    Dim mvda as New Microsoft.VisualBasic.Devices.Audio()

    as

    mvda.Play(path, Microsoft.VisualBasic.AudioPlayMode.Background)

    Why is this error happening?

    The hosting server is set for Medium trust level.

    Is there any way I can avoid this without changing my local set-up?

    Or, how can I correct this by changing my local setup?

    When I set my local system to Medium trust, my MySql data connections don’t work, and I can see I am going to go down a deep rabbit hole in trying to fix this from my side.

    I am using VWD 2008, so the option to publish my site using it as you can with VS is not available.

    Thanks in advance.

  18. 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.