Software Execution Policies in Windows 2000

In Microsoft Windows 2000, software execution control is handled through Group Policy Objects (GPOs), primarily leveraging shell-level execution limits, Windows Installer policies, and NTFS permissions. Although the dedicated Software Restriction Policies (SRP) framework was later introduced in Windows XP and Windows Server 2003, Windows 2000 provides administrators with several core mechanisms to restrict unauthorized software execution across local machines and Active Directory domains.

Group Policy and Administrative Templates

Windows 2000 manages application execution primarily through the Group Policy snap-in (gpedit.msc). Under User Configuration > Administrative Templates > System, administrators can configure two foundational execution policies:

  • Run only allowed Windows applications: Specifies an explicit allowlist of executable file names that users are permitted to run.
  • Don't run specified Windows applications: Defines a blocklist of specific executable file names that users are prevented from executing.

When configured, the Group Policy engine applies these settings directly to the user’s registry under: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

The policy creates a subkey named either RestrictRun or DisallowRun, populated with numbered string values corresponding to the permitted or restricted executable file names (e.g., notepad.exe, calc.exe).

Enforcement Mechanism and Shell Validation

Execution restriction in Windows 2000 is enforced at the user interface and shell level by the Windows Explorer process (explorer.exe). When a user attempts to launch a program—whether through the Start menu, desktop shortcuts, Windows Explorer windows, or the Run dialog box:

  1. explorer.exe intercepts the execution request prior to creating the process.
  2. The shell queries the RestrictRun or DisallowRun registry keys to evaluate the target binary name against the defined lists.
  3. If the binary is unauthorized, the shell halts the launch and displays an error message informing the user that the operation has been cancelled due to restrictions in effect on the computer.

Because this enforcement occurs at the shell level, it does not inspect file hashes or digital certificates. The operating system only validates the file name string. Consequently, launching an application through secondary processes, such as cmd.exe, batch scripts, or renaming the binary, can bypass these shell-level policies if additional controls are not implemented.

Supplementary System Restrictions

To enforce stricter execution control and address shell-level bypasses, Windows 2000 integrates complementary controls:

  • NTFS File System Permissions: Administrators rely on Discretionary Access Control Lists (DACLs) within the NTFS file system. By stripping "Read & Execute" permissions from unauthorized user accounts or groups on specific binaries and directories, the operating system kernel blocks execution regardless of the launching interface.
  • Windows Installer Policies: Under Computer Configuration > Administrative Templates > Windows Components > Windows Installer, administrators can enable the "Disable Windows Installer" setting. This prevents users from executing .msi packages to install unapproved software.
  • Command Prompt Restrictions: To prevent bypassing shell restrictions via the command-line interface, administrators can enable the "Disable the command prompt" policy under User Configuration > Administrative Templates > System, which disables cmd.exe execution for the targeted user.