Get a glimpse inside Don Jones' book "Managing Windows with VBScript and WMI" with this series of book excerpts. Below is an excerpt from Chapter 28, "Scripting Security." Click for the complete book excerpt series or purchase the book.
Security Improvements in Windows XP and Windows Server 2003
Windows XP and Windows Server 2003 introduce a new concept called software restriction policies. These policies, which are part of the computer's local security settings and can be configured centrally through Group Policy, define the software that may and may not run on a computer. By default, Windows defines two possible categories that software can fall into: disallowed, meaning the software won't run, and unrestricted, meaning the software will run without restriction. Unrestricted is the default system security level, meaning that by default all software is allowed to run without restriction.
Windows also defines rules, which help to categorize software into either the disallowed or unrestricted categories. By default, Windows comes with four rules, defining all system software -- Windows itself, in other words -- as unrestricted. This way, even if you set the default security level to disallowed, Windows will continue to be categorized as unrestricted.
You can define your own rules, as well.
- Certificate rules identify software based on the digital certificate used to sign the software.
- Hash rules identify software based on a unique checksum, which is different for any given executable file.
- Path rules identify software based on its file path. You can also specify an entire folder, allowing all software in that folder to run or to be disallowed.
- Internet Zone rules identify software based on its Internet zone location.
Therefore, you create rules that allow Windows to identify software. The rules indicate if the identified software belongs to the unrestricted or disallowed categories. Software not specifically identified in a rule belongs to whichever category is set to be the system default.
Suppose, for example, that you set the system default level to disallowed. From then on, no software will run unless it is specifically identified in a rule and categorized as unrestricted. Although it takes a lot of configuration effort to make sure everything is listed as allowed, you can effectively prevent any unauthorized software -- such as scripts -- from running on your users' computers.
Software restriction policies also define a list of filename extensions that are considered by Windows to be executable, and the list includes (by default) many standard WSH scripting filename extensions. The DLL filename
extension is notably absent from the list. That's because DLLs never execute by themselves; they must be called by another piece of software. By allowing DLLs to run unrestricted, you avoid much of the configuration hassle you might otherwise expect. For example, you can simply authorize Excel.exe to run, and not have to worry about the dozens of DLLs it uses, because they aren't restricted. The default filename extension list does not include JS, JSCRIPT, JSE, VBE, VBS, or WSF, and I heartily recommend that you add them. For example, Figure 28.1 shows that I've added VBS to the list of restricted filenames, forcing scripts to fall under software restriction policies.
Figure 28.1 Placing VBS files under software restriction policy control
With effective use of software restriction policies, you can gain immediate and effective control over which scripts run in your environment, as well as control other types of executable software. One of the most effective ways to ensure that only your scripts run is to sign them, and then create a software restriction policy rule that identifies your scripts by their digital signature.
Click for the next excerpt in this series: Digitally Signing Scripts.
Click for book details or purchase the book.
