FullTrust on the LocalIntranet

re: FullTrust on the LocalIntranet

Subli — Mon, 16 Feb 2009 09:09:33 GMT

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

shawnfa — Mon, 23 Feb 2009 22:36:22 GMT

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

Michael — Wed, 25 Feb 2009 19:44:40 GMT

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

shawnfa — Sat, 28 Feb 2009 02:00:37 GMT

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

amish — Tue, 03 Mar 2009 14:58:26 GMT

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>

re: FullTrust on the LocalIntranet

Sune Scherfig — Wed, 04 Mar 2009 22:02:18 GMT

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

shawnfa — Sun, 08 Mar 2009 01:36:44 GMT

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

-Shawn

re: FullTrust on the LocalIntranet

Steve — Tue, 17 Mar 2009 23:53:45 GMT

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

Derek Smyth — Tue, 21 Apr 2009 18:51:04 GMT

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.

Ronak jain — Tue, 19 May 2009 10:31:37 GMT

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

Security Policy in the v4 CLR

.NET Security Blog — Thu, 21 May 2009 22:03:49 GMT

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

shawnfa — Fri, 22 May 2009 00:24:03 GMT

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

shawnfa — Fri, 22 May 2009 00:29:52 GMT

> 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