A few months ago I blogged about a case in which an ill-advised registry hack caused application failure.  I also referred to KB 885409, which lists some of the problems that can arise when relatively untested third party security guidance around file and registry permissions settings are applied, like the Recycle Bins of administrator accounts becoming readable to all users on the system.

So it’s pretty embarrassing when our own security guidance fails in pretty much the same way.

Microsoft’s official Security Guidance for Windows XP includes a set of “optional file permissions” that block all access to various in-box utilities to everyone except Administrators and the SYSTEM account.  The Federal Desktop Core Configuration requires some of these settings for Windows XP, blocking non-administrator access to the following utilities:

arp.exe
at.exe
attrib.exe
cacls.exe
debug.exe
edlin.exe
eventcreate.exe
eventtriggers.exe
mshta.exe
net.exe
net1.exe
netsh.exe
rcp.exe
reg.exe
regedit.exe
regedt32.exe
regini.exe
regsvr32.exe
rexec.exe
route.exe
rsh.exe
sc.exe
secedit.exe
subst.exe
systeminfo.exe
tftp.exe
tlntsvr.exe

Until recently, these lockdowns were included in Microsoft’s Windows XP Security Guide as a security template called “Optional-File-Permissions.inf”.  That template has been removed from the latest version of the security guide, and the list of files has been slightly altered.

Specifically, we no longer recommend blocking access to Regsvr32.exe.  Regsvr32.exe is a utility that is used to register COM and ActiveX DLL components, the vast majority of which can be registered only by administrators.  However, it turns out that Regsvr32 is also invoked a couple of times when a user first logs on to a computer as part of the creation of that user’s profile.  If a non-administrative user cannot execute Regsvr32.exe, then several parts of user profile setup do not happen.  These include the creation and/or initialization of the user’s My Documents, My Pictures, My Music, Recent Documents, Send To, Favorites, and Quick Launch folders, MUI cache (for localized text), and many default visual settings.  The Windows Shell team never tested under that configuration, and informs us that blocking access to Regsvr32 leads to a possibly unsupportable configuration.

Oops.

Note that none of these restrictions have ever been part of the security guidance for Windows Vista nor for Windows 7, and that the FDCC mandates file permissions changes only for Windows XP.

[Aaron’s Personal Opinion follows…]

I have never been a fan of any of these file restrictions, at least not on a general purpose computer that non-administrators routinely log into.  Some of the utilities (such as at.exe and secedit.exe) require administrative rights anyway and so nothing is gained with further restrictions.  Many others (such as net.exe, attrib.exe, reg.exe, and subst.exe) are frequently used in logon scripts and other batch files for routine and legitimate user profile maintenance and user session/environment setup.  MSHTA enables the use of HTML applications.  None of these utilities allow a non-administrative user to do anything that the user can’t do through scripts and/or graphical interfaces.  They certainly do not allow the user to elevate privilege or to perform administrative operations.  But creating a mapped drive using VBScript is a lot more complicated (and thus error prone) than using NET.EXE.  In my opinion, these settings cause far more trouble than they’re worth.