Partager via

Problems with FDCC’s XP File Permissions

  • Article

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.

Comments

  • Anonymous
    January 01, 2003
    Hi Aaron, regarding restricting built-in commands, I strongly agree. Often it's just security through obscurity - cmd.exe forbidden, however renamed copy cmdx.exe allowed :( I usually leave default settings and just restrict access to application folders based on groups (TS-based environment) Martin

  • Anonymous
    January 01, 2003
    Hi Aaron, Any idea if the FDCC settings for Windows XP will be updated to reflect this new advice? Like you and Martin, I never understood the purpose of changing those permissions.  Users couldn't perform operations they didn't otherwise have rights to do, so restricting them just makes simple things like drive mapping much more complicated than they need to be. Thanks for the great blog!  Looking forward to FDCC on Windows 7.. I guess... ;-) --Matt