Custom Zones and the CLR
On the topic of zones and the CLR ...
Windows lets you define custom zones outside of the standard ones that the CLR knows about (see MSDN's topic on Security Zones for more information). However, because the CLR doesn't know about them, generally any assembly loaded from one of those zones will not get any CAS permissions. This stems from the fact that default policy starts by switching on which zone an assembly is loaded from; since the custom zone won't have a matching ZoneCodeGroup it will end up with Nothing.
The CLR does provide a registry key to help out in this scenario however. If you set the DWORD HKLM\Software\Microsoft\.NETFramework\<version>\Security\Policy\TreatCustomZonesAsInternetZone to 1, the CLR will give any assembly loaded from a zone it doesn't recognize Internet zone evidence.
In the SSCLI, the source for this feature lives in clr\src\utilcode\overrides.cpp -- check out the ApplyCustomZoneOverride function. This function takes in a pointer to what the CLR currently thinks the zone is, and if the above registry key is set, switches that value to be Internet.
An interesting quirk is that this is not actually wired up in the default SSCLI, since it's implementation of zone mapping is much simpler than the standard CLR. If you do want to beef up the zone mapping logic, and potentially wire in a call to ApplyCustomZoneOverride you'll want to check out SecurityPolicy::QuickGetZone in the clr\src\vm\securitypolicy.cpp file.
