 |
It’s All About Security
With .NET Security Policies, you can protect users from accidentally running code from unknown sources.
|
|
Security Policies in .NET are a necessary pain. Without them, letting users point their browsers to any URL, download a .NET executable, and automatically run it on their computers is every virus writer’s dream come true. With Security Policies in .NET, you can protect users from accidentally running code from unknown sources.
You have probably heard before that .NET is highly integrated with the operating system. Security is one area where this integration is particularly evident.
.NET Security Policies are very powerful and highly configurable. Let’s take a look at how these policies are structured and how you can configure them to allow users to download executables from trusted URLs.
.NET Security and Internet Explorer Security Settings
The first place where you can configure security settings to allow users to run executables via HTTP is, not surprisingly, in Internet Explorer. To do so, launch Internet Explorer, go to the Tools menu option, select Internet Options, click on the Security tab, select Trusted sites, and click on the Sites button.
Let’s add http://127.0.0.1 as a trusted site (Figure 5). Notice that the Require server verification… checkbox is unchecked in order to be able to add this site to the list.
Now that http://127.0.0.1 is a trusted site, let’s try to run the executable again with the URL http://127.0.0.1/CodeDownloadDemo/Loader.exe Now the application will actually run, although .NET lets us know that some security issues are still unresolved (Figure 6).
Figure 6: The information icon indicates that the application runs in a partially trusted context. |
? |
Figure 7: .NET generates an error if you try to access resources outside the partially trusted site. |
You can see that the loader application actually ran this time. Notice the small information icon on the upper left corner that indicates that this application is running in a partially trusted context and therefore some features of the application might not work. For example, trying to load data from the Employees Form generates a security error (Figure 7). The form is attempting to read data from SQL Server’s Northwind database in localhost and the application does not have security permissions to do it.
Notice also how the URL (127.0.0.1) and the word “trusted” have been added to the application’s title bar.
.NET Security and the Framework Configuration Tool
Although Internet Explorer allows you to configure some of the security settings for .NET applications, it does not provide a comprehensive list of things that you can allow or deny to .NET applications.
In order to get access to the full range of security options available to .NET applications, you need to use the .NET Framework Configuration Tool. This tool is part of the .NET Framework (not VS.NET), which means that every user with the .NET Framework installed has the Configuration Tool installed as well. To launch it, go to the Windows Control Panel, select Administrative Tools, then choose Microsoft .NET Framework Configuration.
Using this tool, you can configure .NET Security Policies and decide what locations you want to trust and the degree of privileges that a location will receive.
 |
|
| Figure 8: Using the .NET Framework Configuration Tool to configure Code Groups and Permission Sets |
A complete explanation of .NET Security Policies and the tools to configure them is beyond the scope of this article. But let’s take a brief tour of how to use the .NET Framework Configuration Tool to configure Code Groups and Permission Sets (Figure 8).
In Code Groups, you categorize which code is to be trusted and which code is to be denied access. You can probably recognize that the predefined code groups in the Figure 8 correspond to the Zones that you saw in the Internet Explorer Security Setting.
Permission Sets are a means to assemble various permissions under a single name. For example, Figure 9 shows the permissions assigned by default to Permission Sets LocalIntranet and Permission Sets Internet.
Figure 9: Default permission sets |
? |
Figure 10: Defining custom Code Groups and Permission Sets |
You can define custom Code Groups and Permission Sets by right-clicking in the appropriate node. For example, follow these steps to give full trust to code coming from URL http://127.0.0.1 so that the previous example does not raise any security errors:
- Open the Code Groups branch, right-click on the All_Code branch and select New (see Figure 10).
- Enter a name for the new Code Group, perhaps MyCodeGroupFor127, and then click Next
- Select URL as the condition type for the code group and enter http://127.0.0.1/* as the URL to trust (see Figure 11), and then click Next.
Figure 11: Choosing a URL condition type for a code group |
? |
Figure 12: Assigning a permission set to a code group |
- Finally, select Full Trust (see Figure 12), and click Next and then Finish.
Now, if you go back to Internet Explorer and launch the loader.exe program with the URL http://127.0.0.1/CodeDownloadDemo/Loader.exe, the application will run without Security problems. You can even go to the File menu, and then launch the Employee Form and load Employee data with no problems.
In the previous example, you gave Full Trust to a URL. This is not a problem for a demo; but in production environments you need to be more selective and give locations the minimal permissions required in order for them to work properly. Your network administrator will probably not let you grant permissions otherwise.
I highly encourage you to play with this configuration tool and learn about how to create groups and permission sets that will match your particular security requirements.
Deploying .NET Security Policies
In the previous section, you created a security policy to trust code coming from the URL http://127.0.0.1. You wouldn’t want to have to ask your users to follow the same steps as you did to trust your assembly on their computers, would you?
Fortunately, once you have defined a Security Policy, you can distribute it to your users and have them add it to their system with a single click.
You can use the .NET Framework Configuration Tool to configure a wide range of security options available to .NET applications.
|
|
After you define a Security Policy, you can create a Deployment Package that installs the Security Policy via a Windows Installer File (an .MSI file.) To create a Deployment Package, simply right-click on the Runtime Security Policy branch, and select the Create Deployment Package option (see Figure 13).
 |
Assembly.LoadFrom Revisited
Now, let’s review what .NET does behind the scenes when you use the Assembly.LoadFrom method to load an assembly from a remote location. Let’s take this code for example:
'Define URL. Dim URL As String URL = _ "http://localhost/CodeDownLoadDemo/ModuleA.DLL" 'Load assembly from the URL defined above. Dim a As [Assembly] a = [Assembly].LoadFrom(URL)
When .NET executes the LoadFrom method, it goes to the URL http://localhost/CodeDownloadDemo and looks at the ModuleA.DLL assembly on the Web server. .NET verifies whether you have downloaded this assembly before. If you never have, .NET downloads this assembly and stores it in the .NET Assembly Download Cache.
The second time you run this same code, .NET realizes that the assembly has been downloaded before. If the version in the Web server is the same as the one that you have in your Assembly Download Cache, .Net uses the one that you already have on disk.
Let’s say that you run this code a third time and .NET realizes that the version on the Web server is more recent than the one that you have on disk. .NET automatically downloads the new version, stores it in the Assembly Download Cache, and runs it.
The Assembly Download Cache is a special folder located under c:windowsassemblydownload. Figure 15 shows how the assembly cache looks on my computer.
| |
he .NET framework provides new tools to make deployment of fat client .NET applications easier. This article describes the basics of .NET Auto-Deployment technology and the security mechanism that prevents users from inadvertently running code distributed by hackers and virus writers.
