Welcome to MSDN Blogs Sign in | Join | Help

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.
Published Monday, May 12, 2008 10:49 AM by shawnfa
Filed under: , , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: FullTrust on the LocalIntranet

Monday, February 16, 2009 1:09 AM by Subli

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.

# re: FullTrust on the LocalIntranet

Monday, February 23, 2009 2:36 PM by shawnfa

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

# re: FullTrust on the LocalIntranet

Wednesday, February 25, 2009 11:44 AM by Michael

Hi, Shawn:

How about this scenario.

entry.exe is a managed code on \\root

program1.exe is in subfolder \\root\subfolder

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

# re: FullTrust on the LocalIntranet

Friday, February 27, 2009 6:00 PM by shawnfa

Process.Start is going to kick off a new process, where the full trust root is in \\root\subfolder.  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

# re: FullTrust on the LocalIntranet

Tuesday, March 03, 2009 6:58 AM by amish

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>

# re: FullTrust on the LocalIntranet

Wednesday, March 04, 2009 2:02 PM by Sune Scherfig

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

# re: FullTrust on the LocalIntranet

Saturday, March 07, 2009 5:36 PM by shawnfa

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

-Shawn

# re: FullTrust on the LocalIntranet

Tuesday, March 17, 2009 4:53 PM by Steve

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.

# re: FullTrust on the LocalIntranet

Tuesday, April 21, 2009 11:51 AM by Derek Smyth

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.

# Visual guard for .Net, Visual guard for PowerBuilder, Security Application, Application Security , Authentication and Permission.

Tuesday, May 19, 2009 3:31 AM by Ronak jain

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

# Security Policy in the v4 CLR

Thursday, May 21, 2009 3:03 PM by .NET Security Blog

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

# re: FullTrust on the LocalIntranet

Thursday, May 21, 2009 5:24 PM by shawnfa

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

# re: FullTrust on the LocalIntranet

Thursday, May 21, 2009 5:29 PM by shawnfa

> 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

# re: FullTrust on the LocalIntranet

Tuesday, January 19, 2010 11:30 PM by Pennidren

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!

# re: FullTrust on the LocalIntranet

Wednesday, February 24, 2010 12:19 PM by shawnfa

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

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker