This post is a reminder to myself on how to get .Net applications to run over the network. Welcome to security hell <g>...

The issue here is that by default .Net is locked down in such a way that you cannot run an application over the network if uses anything but basic UI manipulation – sandbox mode basically. Essentially the rights of the Intranet are nearly identical to the Internet Zone, which provides the ability to manipulate the UI, read and write protected storage, print and provide access to some dialogs. But it doesn’t include file access, no Interop support at all (which is implicit for most Windows Forms app that use custom controls) and even very limited Internet access (so Web Services won’t even run in most cases). Not the quite enough permissions that you need to run any kind of standard  business application!

So in order to run anything off the network it’s time to make a trip to the .Net Framework Configuration tool, which you can find on the Administrative Tools menu. From the client machine that needs to access the network machine configure the following:

• Go into Machine | Code Groups and add a Code group.
  
• Set the membership condition to: URL
  and set it to: file://OFFICESERVER/*
  or whatever your server name is.
  
• Then set the Permission to full trust.

That should do it for a particular machine on your network. Notice the use of the file:// url that can specify a specific location on the server you need to access.

Instead of setting permissions for a particular machine you can also set permissions on the LocalIntranet_Zone. Here you can set the permissions to full trust as well if you truly have an internal network that contains known content. What’s interesting is, that the default permission set used here is LocalIntranet which is very restricted – only a slight step above the Internet Zone. This Zone doesn’t even include file access by default.

What I find interesting is that this is pretty much a manual process. The Config tool includes a mechanism to ‘export a policy’, but it does so only on the much too wide level of User or Machine or Net or Enterprise level. For a developer wanting to deploy a policy that’s not an option. And a policy file of this nature is really meant as a mechanism for adminstrators to get to each machine and apply it there.

There are a number of APIs that provide programmatic configuration options for this (PolicyLevel, CodeGroup, SiteMembershipCondition etc.) as well as using the command line CASPOL utility to set code access security. With CASPOL you can do something like this for example:

caspol -machine -addgroup 1 -url file://OfficeServer/*

       FullTrust -name OfficeServer_Zone -pp off

More Info and examples on CasPol:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconaddingcodegrouptocodegrouphierarchy.asp

Full Command Line Reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfCodeAccessSecurityPolicyUtilityCaspolexe.asp

Works, but then again when would you really have a chance to do this with an application you need to have run over the network, right? It wouldn’t have rights to execute this, so this would have to be part of an installation package.

There really needs to be an easier way to allow deployment of a policy file with a specific custom permission set that can be clicked on, verified and then applied. The policy file should be an option as part of the application installation. At the end of an install there should be an option to prompt if you want to install the required permission sets. I suppose this can be done now with custom install actions using the above APIs, but that's a pretty hairy process and since it runs code that can't directly be verified also kind of scary.

The process should be verifiable in that it should state where it came from and what the permissions about to be assigned are. And whatever packaging this policy file comes in would have to be able to be executed across the network in some way so it would not fall victim to CAS security in the first place. Wishful thinking for now, but Microsoft has hinted (although not really shown anything concrete) that there will be significant enhancements in this area in Whidbey in the ‘one-click’ deployment scenario.

Always that fine line between usability and security. But somewhere we have to draw the line when software becomes simply unusable because so security is tightened down so tight that you can’t get anything done anymore. Yeah, it’s great I haven’t had any security breach in 9 months, but then I haven’t been able to turn on my computer either in that time, because it was locked up a Level 9 security room! <g>