Deploying Policy on v1.0 and 1.1 of the CLR

A lot of the time, someone has written an application that won't run under the CLR's default security settings and needs to provide a mechanism for their users to modify the policy easily in order to allow their application to run.

For Whidbey, ClickOnce solves this scenario, but for v1.0 and 1.1 of the CLR, there isn't as elegant of a solution.  What you can do on older versions of the CLR is create a MSI file that contains a snapshot of the modified policy.  When this MSI file is installed, it overwrites the user's existing security policy with the one that you specified.

In order to do this, first modify your local security policy to match the policy you want your users to have (see: My application works from my local machine, but throws a SecurityException when I move it to a network share for more details on this).  If you modified the policy in the .NET Configuration Control Panel applet, you're ready for the next step; if you used caspol, open up the control panel applet.

Once you've got the .NET Configuration Applet opened, right click on the Runtime Security Policy node and choose Create Deployment Package.   Choose the policy level that you'd like to export (most likely machine), and specify a path where the MSI file should be created.  Click on finish and the wizard will package up your policy for you.

Now that you have this MSI file, it's up to you to figure out how to push it to your users.  For an application deployed from a website, you might provide a link to the MSI file and tell your users to click on it the first time they run the application.  In a corporate environment, there may be infrastructure already in place to push this update to all desktops.

Of course when ClickOnce ships, the solution to this problem will be to package your application for ClickOnce deployment, and allow the permission elevation infrastructure provide the extra trust your application needs.

Comments

• Anonymous
  September 08, 2004
  Martin,
  
  I don't thing msi just copy a file in a directory because the installation does not apply a policy to a code group if it already exists on the target computer.
  The target policy is not overrided.
  
  There should be some kind of validation somewhere.
• Anonymous
  September 08, 2004
  Hi Fed,
  
  Actually, the MSI will overwrite any existing policy, which is one of the reasons that it isn't as ideal a solution as what ClickOnce provides. Since the policy is overridden by each MSI file, then you run into an issue where each application that requires you to update your policy will overwrite any other apps that have already modified the policy. For this reason, its a good idea to also provide instructions on the website for manual updating of the policy (so that advanced users can do this for more than one application).
  
  -Shawn
• Anonymous
  September 08, 2004
  Hi Shawn,
  
  OK, I redo that again and effectively the policy is overrided.
  I don't understand, because I made a try yesterday and I concluded differently.
  
  :(
  
  Fred
• Anonymous
  September 08, 2004
  Hmm ... well, I can think of two possibilities.
  
  1. You didn't have the correct permissions to overwrite the policy
  2. You accidentally created a deployment package for a different policy level than most of the policy is on. By default, the security policy lives in the Machine level, if you created an Enterprise level MSI, this won't touch the machine level one.
  
  -Shawn
• Anonymous
  September 07, 2005
  Creating the msi file works slick, but my testing indicates running the msi once installs it, second time uninstalls it, third time installs it, etc. We're planning on adding this to the login script, but even standard msi switches to force installation (msiexec /i <filename.msi>) it still toggles install then uninstall.
  
  ??
• Anonymous
  April 03, 2007
  The comment has been removed
• Anonymous
  April 09, 2007
  Hi Jim, If you're trusting based upon strong name, then you could also simply add the StrongName code group as a child of the AllCode root code group.  (ie, don't put it under a Zone group at all).  This way, no matter what zone your strong named assembly is loaded from, it will always be granted trust. -Shawn