Access Denied: Using the Windows .NET Framework to Control Mobile Code

My manager is enthused about the idea of using Microsoft .NET to limit the risk associated with mobile code that users download from the Internet in the form of Web page applets, executables, scripts, and macros. I understand that risk, as demonstrated by Nimda and other blended threats, but will installing the Windows .NET Framework on our client systems help us control such mobile code?

The Framework gives you control over only managed code—that is, code developed specifically for the Framework. Most mobile code today is classic, unmanaged code, but don't let that stop you from rolling out the Framework. In time, more and more code on the Internet will be managed code, and the Framework will give you granular, powerful control over what the code can and can't do within your network.

The Common Language Runtime (CLR—a component of the Framework) consults your enterprise's CLR security policy before executing managed code. While the code is being executed, the CLR remains in control and enforces constraints on the code based on where the code originated and the security policies that correspond to the code. For example, you can define policies that let applications from the Internet at large only execute and display windows but that let applications from a trusted business partner's Web site also print and access the workstation's local file system.

For the time being, unmanaged code such as the types you mention run independently of the Framework. When the number of legitimate developers who are using the Framework reaches a critical mass, businesses will be able to disable unmanaged code from the Internet, or at least severely restrict it. Until then, however, you aren't totally high and dry. Windows XP provides software restriction policies that apply only to unmanaged code.

Software restriction policies let you specify only whether applications can execute—they don't provide the granularity of .NET, which lets you control which resources managed code can work with (e.g., displaying windows, printing files, accessing the file system). Still, software restriction policies are a valuable way to prevent code with a dubious lineage from executing within your network.

To use Software Restriction Policies, open the local Group Policy Object (GPO) on an XP computer. To do so, run mmc.exe, click File, select Add/Remove Snap-in, and click Add. In the Add Standalone Snap-in window, select Group Policy Object Editor, then click Add. In the Select Group Policy Object window, click Finish, then close the other dialog boxes. The Microsoft Management Console (MMC) window displays your local computer's GPO. Navigate to Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies, as Figure 1 shows.

To implement software restriction policies, click Security Levels and choose one of the two defaults. When you choose Disallowed, software won't run, regardless of the user's access rights. Then, double-click Additional Rules in the right pane and specify which applications are allowed to run. If you choose the Unrestricted security level, Windows will let all software execute, subject only to the user's access control. You can create additional rules that allow or prohibit software execution based on the software's Authenticode certificate, a hash of the executable file, Internet zones you've defined in Microsoft Internet Explorer (IE), or simply the path of the executable file.