My application works from my local machine, but throws a SecurityException when I move it to a network share

Programs that run on the CLR use something called code access security (CAS). CAS is different from traditional security systems in that it assigns trust to code rather than users. To do this, the security system gathers a set of evidence about every assembly it loads.  This evidence is then compared against the security policy, and a permission grant is generated. A good reference CAS can be found here:
 
https://msdn.microsoft.com/msdnmag/issues/01/02/CAS/default.aspx
 
One of the pieces of evidence that the security system gathers is the security zone that the code is running from. When you run the code from your local machine, this will be the MyComputer zone, but when you run it off of a server, or even a network share mapped to a drive on your machine, it will be the LocalIntranet zone.

By default any code that is run from the MyComputer zone will get a permission set of FullTrust (unrestricted permission to do anything it pleases). However, by default, there is a more restrictive permission set given to LocalIntranet assemblies.

There are three ways to make an application that works from the MyComputer zone work from the LocalIntranet zone.

1. Determine what permissions are being demanded that are causing your application to throw, and try to modify your application to not require these permissions any more. The SecurityException that is being thrown should tell you which demand
   failed.
2. Give all the assemblies in your application a strong name, and modify the security policy to trust this strong name. (recommended)
3. Modify the security policy to fully trust the LocalIntranet zone. (generally a bad idea)

In order to modify the security policy to trust a specific strong name, you'll first need to sign the assemblies in your application, and give them a strong name, you'll need to generate a strong name key pair using the sn.exe tool:

• sn -k mykey.snk

Once you have this key, you'll need to make sure your assemblies are signed with it.  The easiest way to do this is to add an AssemblyKeyFileAttribute to your assembly.  In the above example, my attribute would be [AssemblyKeyFile("mykey.snk")].  Note, if you are using Visual Studio to build your projects, you'll need to put a path relative to the location VS puts your binary assemblies.  So if your assembly is built to bin\Release, you'd need to use "..\..\mykey.snk".

In addition to a signature, assemblies need to have a version number to have a strong name.  Make sure your assemblies have the AssemblyVersionAttribute on them if you are going to use a strong name.  You will also need to make sure that you give all of the assemblies in your application the strong name signature.

If you don't sign your assemblies, and instead decide to modify your security policy to fully trust the Intranet zone, be aware that any applicaiton that somebody puts on a network share will be able to run unchecked on your local machine.  Since this is a pretty large security hole, it is generally recommended that you trust strong names rather than zones.

The easiest way to modify your security policy is by using the Microsoft .NET Framework Configuration utility from the control panel.  You can also run this tool from the command line by running mscorcfg.msc.

1. Expand the Runtime Security Policy folder
2. Expand the Machine policy level
3. Expand the Code Groups folder

To modify the polcy to trust a specific strong name:

1. Right click on All_Code, and select New
2. Create a new code group for your strong name, and hit next
3. Select a strong name membership condition from the drop down box
4. Hit the import button, and select your assembly.  The configuration tool will import your public key.  If you want to trust everything you sign with this key, leave the name and version boxes unchecked
5. Select the FullTrust permission set

To modify the policy to allow full trust for all Intranet assemblies:

1. Expand the All_Code code group
2. Right click the LocalIntranet_Zone code group, and select properties
3. Switch to the Permission Set tab, and select FullTrust

Updated 7/30/04: Fixed a typo

Comments

• Anonymous
  November 14, 2003
  Good blog!Is it true that in order to run an assembly from a network drive with the recommended method, I have to sign every assembly in my company with the same key, and configure every computer manually (including new ones and rebuilt ones) to trust the common key?If that's the case, then the statement "CAS is different from traditional security systems" is pretty right on!Anyway, thanks for taking the time to explain this all. I'd love to see some recommendations on the first suggestion (handle Security in code). I've seen a lot of posts about Security failures from people trying to read from a DB from the IntranetZone, and their solution is usually just to copy the executable to C:.

• Anonymous
  November 21, 2003
  Yep -- the recommended method would require you to modify the policy on all machines (though, you can use AdminUI to create an .MSI file that does this for you automatically). You don't have to sign everything with the same key, though if you don't you'll have to trust every key that you sign assemblies with.For handling security in code, you just need to make sure that you know what your application is going to require, and attempt to write it in such a way that it won't require a large set of permissions. In our upcoming Whidbey release, we're working on a tool that will help you figure out which permissions your application requires (though it will not be perfect, as this is a very difficult problem to solve).

• Anonymous
  February 26, 2004
  I wonder whether granting Full Trust to an application would be a security leak. Even well-meaning, benign applications could be misused. I'd rather define a new permission set. In my case, I intend to have a two-tier and batch apps, which need access to Sql and File I/O.
  
  My organisation uses a strictly controled shared drive to deploy applications. Executing from a particular shared drive is a trusted operation. On the other hand, applications vary wildly among themselves, and giving the same access to all of them could be counter-productive.
  
  I've worked at another organisation which was using Novell Launcher, which was able to push local copies of executables onto user's machines. Frankly, this sounds like a better solution, especially when the infrastructure already exists.
  
  The complex security model is the price we have to pay to all the malicious hackers. Still, Microsoft could have done a better job at explaining and presenting the model. It is the first dark spot I encounter in Dot Net. Otherwise it is excellent. With a bit of exageration, I could say it is the first MS product which stands on its merit.
  
  Andrew

• Anonymous
  February 27, 2004
  Hi Andrew -- that's a very good point you make there. In fact, I agree that applications should run with the smallest set of permissions they need. While the CAS system does help to prevent overly trusted applications from being tricked by malicious code into doing something bad (since a full stack walk will hit the malicious code, which presumably doesn't have the level of trust required, and throw), minimizing the set of permissions your application is running with is always a good idea.
  
  The problem, at least on v1.0 and v1.1, is that it is very hard for developers to figure out exactly what set of permissions they actually need to run with. We're working very hard to solve that problem on Whidbey in a number of ways. Many of the key improvments are integrated into the Visual Studio environment itself, for instance there will be a "Debug in Zone" feature, that allows developers to say that their app will be run from the intranet, so the debugger should run it with only the intranet set of permissions. This will allow earlier catching of security exceptions, and allow the developer to think of alternate, less-privilaged ways of doing things.
  
  Another VS improvment will be in debugging the security exceptions themselves. Thee is enhanced security exception support, where the VS debugger will show you what exactly caused the exception and give you tips on solving the problem.
  
  I plan on writing a post in a few weeks on tools that we're working on to allow developers to determine exactly what permissions their application requires in order to run. This tool, combined with the enhanced VS support for debugging security problems, should help to enable the least-privilege scenario you describe.

• Anonymous
  March 15, 2004
  The comment has been removed

• Anonymous
  March 17, 2004
  Hi Jane,
  
  I'm not a remoting guru, so I'm just going to take a few guesses here. First off, trusting System.Data.Dll didn't work, because your demand is failing somewhere else on the call stack. It's possible that since you're using HTTP and ASP.Net that you're getting assigned Internet evidence instead of LocalIntranet. In that case, you could try trusting the Internet zone (only for a test run obviously). If this works, I would then create a sub code group off the Internet Zone, possibly using Url evidence to create a safer trust environment. I'd be interested to know if this works, or if it didn't. Thanks.
  
  -Shawn

• Anonymous
  March 19, 2004
  Thanks for taking time for my questions. The LocalIntranet_Zone finally works. The problem was that I need to restart the machine to activate the changes made to the LocalIntralnet_Zone. I find out that I only need SQL Client permission for using System.Data.dll instead of the fulltrust. That is nice because it won't risk the security of the machine so much.
  Distributing assemblies is really giving me a hard time. The reason if using .NET Remoting for our project is that we want to store all of business logics on application farm. In another word, no assemblie related to business logic or database access should appear on the web farm. However, I found out that whatever assemblies appear on the application farm, a copy of them is needed on the web farm. THis is ridiculous. I think I realy should try if interface_based programming works.
  
  -jane

• Anonymous
  April 27, 2004
  Thanks

• Anonymous
  May 20, 2004
  Hello,
  This post helped us get our new .NET application running from a shared network folder and works fine as an internal application for our small company. But it's not clear to me how we're supposed to deal with .NET applications intended to be deployed to our customers' PCs. Are we supposed to ask our customers to change trust levels through the Control Panel? Or blindly run a policy MSI? If we create a policy MSI for them to install, how do we keep that MSI from overwriting or replacing any existing policies? We're new to .NET and have just stumbled upon some of these .NET security and deployment issues, and any help would be greatly appreciated.

• Anonymous
  May 20, 2004
  Hi Steve,
  
  Glad the post helped you get everything up and working. As you've discovered, currently the only way to get policy deployed across the enterprise is with some sort of group policy. And unfortunately, you cannot do this without overwriting everyone's customized policies. (However, most people do not change their policy, so this shouldn't be much of an issue).
  You could also offer the option of installing the policy .msi on a web page with your application, and have only people who need your app change their policy.
  For Whidbey we're working on ClickOnce ... a way to distribute applications that esentially solve this problem. Each application will know the set of permissions it requires, and users can allow, on a per-app basis, each app to run with those permissions.
  
  -Shawn

• Anonymous
  May 28, 2004
  I have an application that is used to transform XML instances. The application allows the user to select two input XML instances and one output XML instance, then it executes an XSLT transform on the two input instances and writes the results to the selected output instance.
  
  This application is located on an intranet server and is available to our users via a mapped network share. Obviously I have a problem, as the LocalIntranet zone does not permit full IO Permissions and my application needs them to not only read in the user's files, but also to write out the results. My solution was to digitally sign my application (ie: giving it a strong name) and to add a Code Group (child to the LocalIntranet_Zone code group) granting the necessary permissions to any application signed with this certificate.
  
  To test my theory, I started by setting my LocalInternet_Zone itself to Full Trust, and my application behaved as desired. Next up, I signed my application and created the Code Group within the LocalIntranet_Zone. To begin testing, I decided to assign any application signed with my certificate the FullTrust permissions. I reset my zone permissions and tested my application. It appeared to behave as expected, however the output produced was wrong: only one of the two input XML files was processed!
  
  My theory behind what's happening is this... my assembly is signed with my digital certificate, and thus my assembly is getting the necessary FullTrush permissions. However, the XslTransform object I'm using from the .NET Framework, being in a seperate assembly not signed with my certificate, is still using the default LocalIntranet_Zone permissions, which is to say limited IO permissions. As such, the document() statement in my XSLT file which loads in the second input instance is failing and I only get the first input instance on the other end of my transform.
  
  Thus, my question is this: what is the proper way of assigning permissions to my application such that not only my assembly has the proper permissions, but also ajoining .NET Framework assemblies?
  
  Thank you for taking the time to assist me,
  
  Jonathan Evraire
  jonevrai at justice.gc.ca
  

• Anonymous
  May 28, 2004
  Hi Jonathan,
  
  I doubt that the problem you're having is what you describe. The System.Xml classes live in System.Xml.dll, which is located on the local machine and will get FullTrust due to that. (Each assembly will get different grant sets, so the fact that your app runs off a share doesn't stop System.Xml from getting full trust). In fact, there's an additonal code group hanging off the MyComputer code group that matches the strong name of the System.Xml assembly (and several other Microsoft assemblies), so even if you change the trust level of the MyComputer zone, this will still recieve full trust.
  Another hint I have that this isn't the problem is that you don't see a security exception anywhere. The only way that this might be security related is if some code somewhere is swallowing the exception. You might want to try hooking a debugger up to your application and trapping first chance exceptions to see if that is the case.
  
  -Shawn

• Anonymous
  May 28, 2004
  The comment has been removed

• Anonymous
  June 01, 2004
  Further testing has revealed that, when my xslt stylesheet is located on the C: drive, the document() function succeeds. However, when my xslt stylesheet is on a network drive, the document() function fails. Or, in other words, it would appear that whenever my xslt stylesheet is in a zone that has FullTrust, the document() function succeeds, but when it's in a zone with partial trust document() fails, even if the application itself has FullTrust.
  
  My question now becomes, how can I have my xslt stylesheet on a network drive and still get document() to succeed?
  
  Thanks for any help you could provide,
  
  Jonathan Evraire
  jonevrai at justice.gc.ca
  

• Anonymous
  June 01, 2004
  From the .NET Framework help topic "XslTransform Class Implements the XSLT Processor":
  
  "Most of the Load methods also take Evidence as a parameter. The Evidence parameter is the System.Security.Policy.Evidence that is associated with the style sheet. The security level of the style sheet affects the security level of any subsequent resources it references, such as the script it contains, any document() functions it uses, and any extension objects used by the XsltArgumentList.
  
  If the style sheet is loaded using a Load method that contains a URL parameter and no Evidence parameter, the evidence of the style sheet is calculated by combining the given URL with its site and zone."
  
  I'm guessing this is what's happening: I'm merely providing a URL to the stylesheet without any Evidence. I guess the solution to my problem would be to provide the necessary Evidence to permit my stylesheet to load outside documents, but how do I do that?
  
  I'll get to the bottom of this eventually! :) I hope my trials will be beneficial to other visitors to this site.
  
  Jonathan Evraire
  jonevrai at justice.gc.ca
  

• Anonymous
  June 01, 2004
  Hi Jonathan,
  
  When you posted about the issue with moving the stylesheet, it occured to me that this is exactly what is happening. This pattern is used in several places across the runtime, where input data is from a potentially untrusted source. You found the example of the stylesheet, this is also true for XML Decryption in Whidbey. Since both of these types of documents can cause arbitrary code to run on the user's machine, they need to be provided with Evidence, otherwise we don't know how much you trust the documents. I'm willing to be that once you provide Evidence to your stylesheet that points it to a zone you trust, you'll be able to make this work. Another alternative would be to modify your policy to trust the URL where the stylesheet is loaded from.
  
  -Shawn

• Anonymous
  July 22, 2004
  Great blog, thanks for the info. I'm having trouble setting up jit debugging so I can look at exactly where SecurityExceptions are thrown. I followed the
  directions given in the dialog launched by IE to set <system.windows.forms jitDebugging="false" /> into the <configuation> section of machine.config or web.config for the site (hosted in IIS). This didn't work though - the dialog still came up, still no way to attach a debugger. Any ideas? I also tried putting it in the whatever.exe.config file.
  
  <pedantic>Typo in first post - mscorcfg.mmc should be mscorcfg.msc :-)</pedantic>
  

• Anonymous
  July 28, 2004
  The comment has been removed

• Anonymous
  July 30, 2004
  Joe #1 -- thanks for the info on the typo ... I've updated the post. As for your ASPX debugging question, I'm not really an expert in that area. Try hitting the microsoft.public.dotnet.framework.aspnet newsgroup and seeing if they can help you out in there.
  
  Joe Goeke --
  
  This is a problem we fixed in Whidbey, the Security Exception is now greatly improved. It shows you the demand that failed, the granted set of the assembly, the action that failed, and the zone of hte assembly that failed. Also Visual Studio 2005 will catch security exceptions where they're thrown, and provide help on solving the problem. VS 2005 also allows "Debug in Zone", which enables you to debug as if your app was on the Internet or Intranet.
  
  -Shawn

• Anonymous
  July 30, 2004
  Just to add to my above comment, I posted a new blog entry today about the enhanced security exception in Whidbey. http://blogs.msdn.com/shawnfa/archive/2004/07/30/202468.aspx
  
  -Shawn

• Anonymous
  July 31, 2004
  Hi There,
  
  thanks for the great article!
  
  We are moving over 100 websites to a new webfarm. The majority of these sites are .NET with no strong named assemblies.
  
  I have a Win2003 Domain Controller which hosts my SQL 2000 database, a win2003 webserver which will host the many web applications that now write to a network share. I am getting the error System.Security.SecurityException: Request for the permission of type System.Data.SqlClient.SqlClientPermission in my .net pages (however this works fine when moving the site to the local disk).
  
  I did change the machine.config file for the aspnet_worker process to run under a Domain user instead of machine.
  
  I tried modifying the LocalINtranet_ZONE to full trust to see if it works. After rebooting the webserver it did not resolve the problem. Do I need to make changes to the Domain Controller as well which hosts the database?
  
  Any help appreciated.

• Anonymous
  August 02, 2004
  Hi Matt,
  
  Unfortunately, I'm not an ASP.Net expert, so I'm not sure what steps you should take next. I would recommend hitting up the microsoft public newsgroups, specifically microsoft.public.dotnet.aspnet to see if someone there can provide you with some information.
  
  -Shawn

• Anonymous
  November 17, 2005
  The comment has been removed

• Anonymous
  December 06, 2005
  It's Really working..But i want the key as public.how to use the created key as a public key to make use of the web to run in different systems.i have a application in windows and importred to web page. its working in local.

• Anonymous
  December 19, 2005
  I have a C# app and C# class library (.NET 2003) deployed on a network drive. Doesn't work because of a SecurityException that occurs before Main () is called. The debugger says the following:
  
  A first chance exception of type 'System.Security.SecurityException' occurred in mscorlib.dll
  
  Additional information: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  
  A first chance exception of type 'System.Security.SecurityException' occurred in mscorlib.dll
  
  Additional information: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  
  A first chance exception of type 'System.Security.SecurityException' occurred in Unknown Module.
  
  Additional information: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  
  A first chance exception of type 'System.Security.SecurityException' occurred in Unknown Module.
  
  Additional information: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  
  An unhandled exception of type 'System.Security.SecurityException' occurred in Unknown Module.
  
  Additional information: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  
  
  Unhandled Exception: System.Security.SecurityException: Request for the permission of type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
  at Senco.ScrapTrackerAdmin.ScrapTrackerAdmin.Main()
  
  The state of the failed permission was:
  <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
  version="1"
  Flags="UnmanagedCode"/>
  The program '[3796] ScrapTrackerAdmin.exe' has exited with code 0 (0x0).
  ------------
  I do not have any unmanaged code in my app or my class library (no P/Invoke calls).

• Anonymous
  January 17, 2006
  The comment has been removed

• Anonymous
  January 18, 2006
  My guess is that you're hitting a LinkDemand for FullTrust in your code. See http://blogs.msdn.com/shawnfa/archive/2006/01/11/511716.aspx for more details.
  
  -Shawn

• Anonymous
  January 18, 2006
  The comment has been removed

• Anonymous
  January 23, 2006
  Thanks for the info this was the first article that gave me an understaning of how the security framework actually works in .NET.
  
  The problem is that I continue to get the same security exception problem. My situation is as follows:
  
  Created a DLL and EXE. These worked fine on local machines but on moving to a network drive experienced problems.
  
  Steps to resolve:
  1. Retested on local machine - worked fine.
  2. Signed both DLL and EXE with same "strong name" key - did not work.
  3. Created a new permission in the .net 1.1 configuration wizard - attempted to import public key from assemblies (DLL and EXE) - Error was received that "assembly does not appear to be valid" and thus could not import.
  4. Using sn.exe printed out the public key and pasted it into the permissions in the config wizard - did not work.
  5. Modified intranet permission to 'fulltrust' for testing purposes - did not work.
  6. Modified all permissions in the local machine to 'fulltrust' - did not work (reset all permissions)
  7. Merged EXE and DLL into a single EXE - could still not import public key.
  
  The actual error I am experiencing is :
  
  "System.Security.SecurityException: Request for the permission of type 'System.Data.Odbc.OdbcPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
  
  I am using the .net 2.0 framework. Any help would be greatly appreciated

• Anonymous
  February 07, 2006
  Expand the All_Code code group
  Right click the LocalIntranet_Zone code group, and select properties
  Switch to the Permission Set tab, and select FullTrust...
  
  I can do it for .NET 1.1, but there is no ".net configuration utility" in .NET 2.0. We installed .NET framework 2.0 but didn't see any new shortcuts in control panel.
  
  What should I do to allow full trust in local intranet for 2.0 application?
  
  thanks

• Anonymous
  February 08, 2006
  Hi Dmitry,
  
  The MMC snapin you're asking about was moved to the SDK for v2.0.  (See http://blogs.msdn.com/shawnfa/archive/2006/02/08/527663.aspx).
  
  -Shawn

• Anonymous
  February 14, 2006
  Just simple comment, I find it simpler to grant trusts to Local intranet through the .Net cmd prompt. Its also easier to push to clients, if you're not using gpo's.
  
  
  To grant FullTrust to the LocalIntranet (1.2) simple type:
  
  caspol -cg 1.2 FullTrust
  
  

• Anonymous
  February 23, 2006
  After a lot of searching I essentially resolved my problem as logged earlier.
  
  Point 1:
  I followed all instructions here but I was using the ".Net Framework 1.1 Configuration" tool instead of version 2.0.
  
  This explained why I could not import the "strong name" key.
  
  Point 2:
  The configuration tool for .Net 2.0 is not included in the runtime engine for 2.0 but only in the SDK.
  
  Resolution:
  Thus following on from the previous poster "Ryan Mrachek" I used the "caspol" tool but instead of assigning a blanket "FullTrust" I used the "strong name" I had already embedded into my assembly.
  
  Here is the command I used -
  
  caspol -ag 1.3 -strong -file myfilename.exe AName_I_assigned -noversion FullTrust -n AName_I_assigned
  
  I placed it into the 'Internet' zone (1.3) since this is where the application was running when executed over a network share.

• Anonymous
  March 01, 2006
  Would a reboot be required after the steps above for "To modify the polcy to trust a specific strong name"...?
  
  

• Anonymous
  March 02, 2006
  A reboot will not be required, but you will have to restart your process.  CAS security settings are read at process start, and will not be reread during your process lifetime.
  
  -Shawn

• Anonymous
  March 09, 2006
  What is the reasoning in the security model, where a .Net executable on a network shared drive does not have full access? If non-.Net executables and scripts still have full access. Is something being changed in Whidbey to address this?

• Anonymous
  March 16, 2006
  I am looking at how we implement .NET security on our estate. One thing concerns me the application one of our develops has sent me doesnt use strong names. It works if i copy it to the local drive as by default it has FullTrust.
  
  If its on a network it doesnt work
  
  Isnt there a security hold where develops would write what they want then copy it to the local drive to run it.
  
  Shouldnt the My_computer be locked down as well?
  
  Thanks

• Anonymous
  March 17, 2006
  Hi Joe,
  
  If a malicious developer can convince the user to copy their code to the local machine and run it, then the game is already over.  If the user is willing to do that, what would prevent them from running a caspol command that the malicious developer handed them, then running the code?
  
  -Shawn

• Anonymous
  April 07, 2006
  The comment has been removed

• Anonymous
  April 17, 2006
  The comment has been removed

• Anonymous
  April 18, 2006
  Another solution is simply to turn off CAS..
  caspol -s off
  Depends on what your envirionment is, but we are implimenting an app that uses the "thin client" (http://www.developer.com/lang/other/article.php/929071) and we are deploying it in an intranet where there is full control of the evironment.. so we simply turn off security checking, run the request for the remote DLL so that it is downloaded to the cache, then turn the security checking back on. Works well for us.
  John
  

• Anonymous
  April 19, 2006
  Turning CAS off is absolutely not a good option.  When you do that, you're allowing any managed code from anywhere in the world full access to your machine.  With v2.0 we've made caspol -s off a temporary operation, and in future versions it may be removed entirely.
  
  -Shawn

• Anonymous
  April 27, 2006
  I see in this thread an example of a caspol command that is supposed to grant local Intranet permissions to an app.  Do I have to run this on every machine that needs the application?  What if I have a large number of users that need the app? Do I have to go around to every machine?  (Yes we have GPOs in place.) I can't install this app locally; it must be called from a central network location.  
  
  I understand the need for security, but this trusted assembly stuff is way overboard.  Why do I have to beat my brains out trying to get an application to run where I want it to run after I've run it flawlessly in local dev?  We have a VERY strong Active Directory policy and organization in place; why won't that suffice?
  
  Phew.  This is very frustrating (what, you can't tell from my rant?). It would be nice if someone produced some CLEAR and CONCISE instructions to network-enable my app, instead of the MSDN mumbo-jumbo I've been plowing through for the last two days.
  
  OK, I'm done.

• Anonymous
  April 27, 2006
  Hi Phil,
  
  Yes you have to trust the code on every machine that will run it.  You can use the .NET Configuration Wizard in the control panel to create an MSI that you deploy via GPO to simplify things for you.
  
  Just because code is trusted to run on a developer's machine doesn't mean every user trusts it to run.  In that case, any developer of malware would simply say "Oh yes, this is trusted code.  Nothing to see here, move on."  Obvsiously that's not an ideal sitaution :-)
  
  -Shawn

• Anonymous
  May 01, 2006
  The comment has been removed

• Anonymous
  May 01, 2006
  The comment has been removed

• Anonymous
  May 08, 2006
  I don't know if you guys solved the problem but this works...
  
  Expand the All_Code code group under Administrator Tools/Microsoft .NET Framework 1.1 Configuration
  Right click the LocalIntranet_Zone code group, and select properties
  Switch to the Permission Set tab, and select FullTrust...

• Anonymous
  May 15, 2006
  Doing that opens up any code that someone can get onto your Intranet to run unrestricted on your local machine.  Depending on your network configuration, this may or may not be an acceptable solution.
  
  -Shawn

• Anonymous
  May 22, 2006
  I have a Windows Forms app that will be installed on a network share.  I did not sign every assembly with a strong name, but instead granted FullTrust to the network share itself.  In other words, I added a new group on the Machine -> All_Code specifically for my application.  I set it's condition to URL with the url specifying the specific shared folder with a wildcard at the end of the folder name: (file://server/folder/*)
  
  This folder has been granted right by our security department to only a few individuals.  
  
  Does this open the whole Intranet or only the code in that folder?  Do you fell this is a large security leak?
  
  Thanks

• Anonymous
  May 23, 2006
  Hi Chris,
  
  That sounds reasonable -- as long as you're willing to trust anyone who can get code onto the share, trusting the share itself is fine.
  
  -Shawn

• Anonymous
  May 26, 2006
  The comment has been removed

• Anonymous
  June 01, 2006
  The comment has been removed

• Anonymous
  November 01, 2006
  For those who want a sample step by step on how to create a key and a sample application go here: http://jhermiz.googlepages.com/serverapp

• Anonymous
  November 08, 2006
  I am getting a "Request for the permission of type System.Data.SqlClient.SqlClientPermission, System.Data, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed."  I have registered the strong names of the DLL that uses these DLLs.  What do I have to do next?

• Anonymous
  November 14, 2006
  You'll need to attach a debugger and examine the call stack at the time of the failure -- there may be an unelevated assembly or AppDomain on the stack (or a PermitOnly or Deny). -Shawn

• Anonymous
  December 10, 2006
  plz help me i am getting error given below :- Security Exception Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Data.Odbc.OdbcPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. what can be solution for this problem?

• Anonymous
  December 12, 2006
  The comment has been removed

• Anonymous
  December 12, 2006
  It seems CASPOL actually works for users as well as administrators but it will apply settings for the current user rather than machine-wide. I suppose this means I can add a call to CASPOL in my application's installer and change the user settings that way. Obviously .net gives you a fake sense of security since any application can install with a call to CASPOL and open up the intranet to any other .net application that requires fulltrust. Why isn't there some provision for an interactive negotiation of this? My users wouldn't mind a message that says something like 'You are running <appname> over the intranet, this is a security risk blablabla do you want to allow access yes/no' Or perhaps the CLR could pop up a message similar to the ones personal firewalls have, with something like '<appname> is being activated over the network. Are you sure you want to allow this yes/no' Well for now running CASPOL in the installer will do fine. Thanks for your informative blog!

• Anonymous
  December 17, 2006
  As you note, if you run caspol as a non-admin you'll by default update the user policy level rather than the machine level. However, each policy level is intersected to get the final grant set.  This means that users can only restrict the security settings of the machine, not increase them. For example, if the machine level granted an assembly the Intranet permission set, and the user level granted it FullTrust, Intranet intersect FullTrust = Intrant.  However if the user level granted it Internet permissions, Intranet intersect Internet = Internet. As for an interactive negotiation, well, that's ClickOnce :-) -Shawn

• Anonymous
  January 14, 2007
  Hi, I am also having similar kind of issue, we have deployed our migrated .Net 2.0 application in virtual folder using IIS, and when we try to access exe through IE, the login window prompts security warning followed by permission alert. please see below "Microsoft .Net security warning : Never enter personal information or passwords into a window unless you can verify and trust the source code of the request." "Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version 2.0.0.0, Culture=neutral, Publikyeotoken=2jksdfhsdjhfsd89' failed." And i have applied the below commands C:WINNTMicrosoft.NETFrameworkv2.0.50727>CasPol.exe -m -ag 1.2 -url http://sonopress-om2/sonobest2/SOSG2.0_UAT/SonoBEST2.0.exe. FullTrust Microsoft (R) .NET Framework CasPol 2.0.50727.42 Copyright (c) Microsoft Corporation.  All rights reserved. The operation you are performing will alter security policy. Are you sure you want to perform this operation? (yes/no) y Added union code group with "-url" membership condition to the Machine level. Success Any help greatly appreciated. Thanks in advance

• Anonymous
  January 16, 2007
  Shawn, Thats a very helpful article solving the security issue on client side machine but is there anyway I can do these settings on server side rather than every client changing their .Net security settings? As it can be a bit of pain for the users  cause every client machine needs to be configured before running my application. Thanks Umer

• Anonymous
  January 17, 2007
  Hi Umer, If you're using v2.0 of the CLR, your best bet is to use ClickOnce, which allows a simple "yes/no" decision on each client machine, and modifies the client machines appropriately. If you can't use ClickOnce however, then you can either create a policy MSI file and push that out via Group Policy, or provide instructions for your clients on your install page.  If we allowed arbitrary servers to update client trust policy, we'd have a problem with malware writers saying "no really, you should trust me :-)". -Shawn

• Anonymous
  February 02, 2007
  I am trying to learn how to use remote debugging with VS 2005 (C#) but am having issues with the security of being able to run it. So I have the application on the remote machine (in a shared directory) and the and VS is all set up on my local machine to remote debug the application.  However I always get the exception "Request for the permission of type 'System.Net.SocketPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed." But I am able to run it fine by navigating to the shared directory over the network.  I have a strong name key in the application and then I had to add a FullTrust for the strong name of the application under the LocalIntranet of the .NET Config tool  to get it to work like this.   Any idea what is causing this?

• Anonymous
  February 05, 2007
  Shawn, I am having the same problem as a lot of people.  I did get my program to run fine over a network share by adding a strong name key and adding FullTrust of that key.  However I am having a problem because I am trying to use Remote Debugging in VS2005.  But I am back to getting all the same security exceptions when I run my program through the remote debugger.  Any ideas as to why this may occur or how to fix it? Thanks Adam

• Anonymous
  February 18, 2007
  How to leave Users to set Admin config task: \serversharerunas.exe /user:axa-assistanceadmin-username "\serversharecaspol -cg 1.2 FullTrust" | \serversharesanur.exe admin-password

• Anonymous
  March 01, 2007
  After reading all this I thought it was going to be a major pain to deploy a C# app but it wasn't too bad.  Unless you enjoy flailing around with a command prompt setting obscure parameters... you can try these steps if you have VS 2005:

1. Right click on the project file and select Properties
2. Select Publish
3. Tell it where on the network to copy the files to
4. There are a few million other settings on this tab that I'm not gonna go over... so goodluck...
5. Have users run the setup.exe from the network and then the program is installed... either locally... or with some kind of shortcut depending on settings you used to deploy.
6. In the future I'm having the IS department install this program on an image used to build new PCs so users don't even have to install. This might not work for everyone but... I thought it might help someone who just needs to get something out there without opening up the local intranet to FullTrust.

• Anonymous
  March 09, 2007
  Hi Jennifer, Absolutely!  That's the ClickOnce feature of .NET 2.0, and if you can use it a lot of security policy problems simply go away. -Shawn

• Anonymous
  March 12, 2007
  Hello, I'm trying to create a new code group using an XML file to import the public key, so instead of having to know where the application was installed, I can run a batch file that calls caspol as a custom action on install. The problem I'm having is that when I try to import the file (even through the .NET 2.0 configuration tool) I get an error stating that "You are trying to load an unknown security type." The contents of the XML file are: <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Test" Description="Test description"> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100CBE718ACE1087986E7530D06C81291887B581BF96BFA007DFF02A29920D466B29029496CACDE914B45BAFAC5152E6ECD1ECFA86E08C00A019E3FFF306D7659D9B0E9C2C77553C53A99594DC211061239956D54B6FF27DA3F0340DB77332B500511EAABAB232B9628CF48A6EACA82B2F028BC71DD725E6AE23552F292B7000BC2"/></CodeGroup> and the command I'm using is: caspol -m -ag All_code -custom ImportCodeGroup.xml I have looked everywhere for an answer on this but can find nothing but questions on the same from others.  As I said this file cannot be imported from caspol or the GUI config tool.  Please help me.   Thanks.

• Anonymous
  March 14, 2007
  The comment has been removed

• Anonymous
  March 14, 2007
  I had to add that you should probably make sure that your target machine has the Framework 2.0 on it..  It took me way too long to figure that out, and I thought maybe it'd save someone else someday..

• Anonymous
  March 15, 2007
  Hi Stuart, Jennifer is referring to ClickOnce, which is accessable via the Publish feature in Visual Studio 2005.  Using ClickOnce you can say that your application requires FullTrust to run, and ClickOnce will generate some manifest files for it. If you have your users run the manifest files rather than your .exe directly, then the application will run with the requested permissions. By the way, the wizard that was available in v1.1 is also available in v2.0.  You just need to install the v2.0 Framework SDK to get it to appear.  You can find mscorcfg.msc in the SDKbin directory. -Shawn

• Anonymous
  April 25, 2007
  Thats really very good information provide. I've an Windows form which is loaded in IE. This windows form interacts with an interop dll (VC dll, which is signed). Both the windows form dll and interop dll are signed and placed in gac. Now, when I try to access the interop dll from my windows form (loaded in IE) it gives me the following exception: System.Security.SecurityException: Request for the permission of the type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKey Token=b77a5c5611934e089' failed. Any help will be highly appreciated

• Anonymous
  May 07, 2007
  Hi Shekar, The AppDomain itself will be partially trusted, so you'll need to make sure that you do an Assert for FullTrust at the top of the callstack, preventing the demand from failing when it walks past the top frame of your code. -Shawn

• Anonymous
  May 11, 2007
  Hi, I used the polcy to trust a specific strong name, but I receive the following error: "System.Security.SecurityException: That assembly does not allow partially trusted callers.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file." I can not put in the web config: "<trust level="Full" />" because it says: "This configuration section cannot be used at this path.  This happens when the site administrator has locked access to this section using <location allowOverride="false"> from an inherited configuration file. " When I use the policy to allow full trust for all Intranet assemblies: I receive the same error: "Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed." I read your instructions, but I can not solve this problem. Help me!! thank you very much.

• Anonymous
  May 14, 2007
  Hi Daniel, The first exception you mentioned means that you need to add the AllowPartiallyTrustedCallersAttribute to your assembly. -Shawn

• Anonymous
  May 21, 2007
  The comment has been removed

• Anonymous
  February 03, 2009
  Hi Shawn, Am using a windows form user control in my web application. I followed the steps u had mentioned in your blog - http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx It works well in my local system. But doesn't work when the rest in intranet accesses my application. Please give your suggestions.

• Anonymous
  February 04, 2009
  Hi Kani, You need to make sure to issue these caspol commands on each computer that neesd to run network code.  The changes you made on your machine do not affect the security policy on other machines, so you'll need to duplicate them there. -Shawn

• Anonymous
  February 10, 2009
  I found this article on msdn on how to create a msi to modify the .NET access. (http://support.microsoft.com/kb/931867) I want to complete steps 1-5 (after the sentence: To make a specific change to the security policy and to avoid overwriting other policies, follow these steps.) so that I don't OVERWRITE the settings they already have.  But I don't understand how to complete steps 1 -5.  Do you know of different instructions that might be easier to follow?  Have you ever done these steps? Thanks for the assistance.

• Anonymous
  February 13, 2009
  The comment has been removed

• Anonymous
  February 16, 2009
  Hi, I created a .Net dll in VS2008 .Net 3.5SP1, to run with Excel 2003. It works well on the local machine and fails on the network. I get a runtime error 80131700. Any ideas? I have granted full trust to the network with the config manager 1.1. I also registered the dll with the /codebase option. I also have a strong key for the assembly. I also placed a config file in the Excel.exe. folder excel.exe.config. I have tried every trick in the book mentioned online. I am completely at my wits end... I cannot start the debugger across the network (placing the sourcecode on the network, compiling and using debugger) since the code does not come into the debugger. it fails before it enters the dll and there is no call stack.

• Anonymous
  February 17, 2009
  Since comments are sill added to this old post, I thought I'd add that this whole issue has been resolved by Microsoft in .NET Framework 3.5 SP1 due to a lot of customer feedback. Read about it here: http://blogs.msdn.com/vancem/archive/2008/08/13/net-framework-3-5-sp1-allows-managed-code-to-be-launched-from-a-network-share.aspx hth if you arrive here in the future :)

• Anonymous
  February 23, 2009
  Yep -- I also covered that here: http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx :-) -Shawn

• Anonymous
  February 23, 2009
  Error 0x80131700 is CLR_E_SHIM_RUNTIME_LOAD.  That means that mscoree.dll couldn't load up the runtime correctly.  You likely have a problem other than security, since you're erroring out long before the CLR security system comes into play. -Shawn

• Anonymous
  April 28, 2009
  PingBack from http://forum.codecall.net/c-programming/15744-c-dll-windows-security.html#post149140

• Anonymous
  May 20, 2009
  PingBack from http://mmlst.com/2009/05/21/microsoft-net-security-warning/

• Anonymous
  July 02, 2009
  We're still ways off from adopting 3.5 SP1, so will have to toil with setting the policy at the machine level. With that, I see this post -- http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx#537883 But not fully grasping how to run caspol to have my app be fully trusted with its snk file.  Don't I have to specify the path for exe and snk?

• Anonymous
  October 05, 2009
  thanks for the solution........

• Anonymous
  November 05, 2009
  Every .NET framework install (each version, and each bitness of each version from v2.0+) have independent CAS policy - so you need to make sure you're using the caspol.exe from the install of the framework that your code is running against in order to get these instructions to work. -Shawn

• Anonymous
  November 05, 2009
  If you want to trust an assembly via its strong name, then you should use the -strong option to caspol and pass it your signed assembly (not the SNK file): caspol -m -ag 1. -strong -file yourassembly.exe -noversion FullTrust You could also add a -noname flag if you want to trust everything signed by that key, although at that point you should put the code group under a different Zone entry (for instance LocalIntranet). -Shawn

• Anonymous
  January 21, 2010
  The comment has been removed

• Anonymous
  February 24, 2010
  As of .NET 3.5 SP1, your executables will run fully trusted off of a share by default: http://blogs.msdn.com/shawnfa/archive/2008/05/12/fulltrust-on-the-localintranet.aspx -Shawn

• Anonymous
  March 21, 2010
  The comment has been removed

• Anonymous
  March 21, 2010
  The comment has been removed

• Anonymous
  March 21, 2010
  The comment has been removed

• Anonymous
  March 31, 2010
  The comment has been removed