I believe in .NET 3.5 there is nothing new around mscorcfg.msc (which will start and run the well known .NET Framework 2.0 Configuration utility) yet it caused a minor puzzling and wondering while trying to setup a well defined policy for a particular .NET executable intended to run on my x64 system. So in this article I will draw your attention on the simple fact that facing this UI depicted below you better bear in mind, this utility targets only the 32 bit .NET Framework! In order to configure x64 assemblies developers and administrators are forced to use the less convenient caspol.exe command line utility.
Note: alternatively this above utility could be also started via “Start/Control Panel/System and Security/Administrative Tools/Microsoft .NET Framework 2.0 Configuration”.
The task I was trying to perform seemed to be quit easy for me. Just restrict the permissions for a locally executing strong named .NET Application which should apply for any user logged on the physical hardware. Nice! I have opened the mentioned above configuration utility and created a new Code Group within the Machine Security Policy level named “Restricted” along with a “Custom” permission set restricting the Application in a prescribed manner. So at the end of the day the configuration resembled to this depicted in the picture below (assuming for test purposes only that this Custom Permission was empty, or in other words it reflected the same Permission Set as the by default existing Permission Set named Nothing):
Also note the checked checkbox at “This policy level will only have the permissions from the permission set associated with this code group”. Without this option my newly created code group would simply inherit the My_Computer_Zone’s Full Trust permissions eliminating the currently set restrictions.
In order to make sure the configuration will truly apply, I have evaluated the concerned assembly in the normal way –> right mouse click on the “Runtime Security Policy” than “Evaluate Assembly…” than "click on “Browse” in order to load the affected assembly. The displayed dialog box listed not a single permission for “All Code” due to the restrictions on the “Machine” policy level. So fine! This means there is no way to run this assembly and any execution attempt (inclusively a double click) on the affected executable must end with an access violation. Next I have navigated my windows explorer to the location of the executable and was trying to run it. First time I was astonished, as the process started and the application executed without any restrictions. What’s going on?
Later I realized, the problem was the Visual Studio project’s property targeting “Any CPU”, which on my x64 OS means simply the default x64. Furthermore please note, on x64 systems there are at least two separate .NET Frameworks installed, one targeting x86 CPU architecture and one more targeting x64 CPU architecture. Looking after deployed .NET Framework Versions and Service Packs there are also two registry locations to look for:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP (x64 CPU)
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP (x86 CPU)
These above registries targeting these file/system locations correspondingly
- C:\Windows\Microsoft.NET\Framework64 (x64 CPU)
- C:\Windows\Microsoft.NET\Framework (x86 CPU)
The problem as you can imagine now was simply, that the nice utility with the graphical user interface targets only the classic 32 bit (x86) Framework leaving completely unaffected the another x64 Framework. In order to configure x64 CPU related assemblies, the caspol.exe utility is imperative. Here the command line I learned to achieve the same settings:
caspol -m -addgroup All_Code -strong -file caller.exe caller 220.127.116.11 Nothing -exclusive on -name Restricted
- -m is for the Machine policy level
- -addgroup means I’m going to create a new Code Group
- All_Code defines the parent of that new Code Group
- -strong specifies code that has a strong name
- -file stands for the file path of the specified code followed by the filename, the assembly-name and version (here: caller.exe caller 18.104.22.168)
- -exclusive set to on means the checkbox described above prevents permission inheritance
- and lastly comes the name of that new Code Group meaning Restricted
Lastly here the command line to remove the above settings:
caspol -u -remgroup Restricted
Additionally some useful links: