Federal Desktop Core Configuration

Job opening: Senior Software Development Engineer

As you may know, the Federal Desktop Core Configuration is largely based on Microsoft’s Security Guidance for Windows.  Well, the team in Redmond that creates and publishes that guidance has a job opening:

Do you have a passion for developing software and want to help our customers become more secure? Interested in making an impact on over 500,000 customers by regularly shipping software every 6-12 months?

Our team ships Solution Accelerators - we accelerate the adoption of the Microsoft platform by incubating exciting future product scenarios today. Our accelerators result in high customer satisfaction, huge downloads, and big changes in upcoming Microsoft products.

The Solution Accelerators for Security and Compliance is comprised of a small number of FTEs that plan, design, develop, and release our products, while managing a few key vendors to do additional development and test work. This high-scale model means that our FTEs focus on the most important aspects of the engineering lifecycle, work with engineering teams across Microsoft, and ensure top quality work from vendors.

If this interests you, check out the job description at https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=2&jid=10062&jlang=EN.

Updated LGPO utility sources

The updated sources corresponding to the updated versions of the Apply_LGPO_Delta and ImportRegPol utilities are attached to this post.

Apply_LGPO_Delta and ImportRegPol updated

I discovered an “unintended feature” in the Apply_LGPO_Delta and ImportRegPol utilities, which I have fixed in the versions now posted to the LGPO Utilities page.  The “feature” (OK, the “bug”) allowed commands to set a registry value and to delete that registry value not to overwrite each other in the resulting registry policy file. This meant that if you had a policy that set a registry value, and then applied a delta file or imported a registry.pol with a command to delete that registry value, the resulting registry policy file would end up containing both the “set” and “delete” commands.  Today’s update ensures that if a “set value” command is applied, any corresponding “delete” command for the same value will be removed, and vice versa.

The updated source is posted here.

Problems with FDCC’s XP File Permissions

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.

Viewing and Comparing IE Security Zone Settings - enhanced

I've enhanced the IE security zone comparison utility that I posted here a few weeks ago.  The new version shows the effective settings for a selected zone, based on the precedence rules for User and Computer policies and preferences (as described here) and whether only Machine settings are used.  Pick an IE security zone (such as Intranet), and the new IEZoneAnalyzer will show what settings are in effect and where those settings come from.

Viewing and Comparing IE Security Zone Settings

The Security tab of the Internet Explorer Properties dialog shows security settings for the Internet, Intranet, Trusted Sites and Restricted Sites zones.  However:

• It doesn’t show settings for the Local Machine (Computer) zone, nor for Local Machine Zone Lockdown (LMZL).
• When machine settings or other policies are in effect, most of the Security Zones UI is disabled.

The attached utility “IE Zone Comparer” was designed to overcome these limitations and provide additional visibility into security zone settings.  Pick any two collections of security zone settings, and IE Zone Comparer displays the values of those settings, highlighting any differences between the two collections.

IE Zone Comparer requires .NET 2.0 or higher; it does not require administrative privileges.

How to use it:

Click “Pick Zones…” from the toolbar.  The following dialog will appear:

The Effective Settings label indicates whether User settings are used or ignored.  Refer to this blog post which discusses precedence order of the various policies and preferences.

For each column, there are two dropdowns.  The first dropdown lets you select Templates, Machine Policy, Machine Preferences, User Policy, User Preferences, or FDCC Q1 2009 Policies.  If you select Templates, the second dropdown lets you select one of the security zone templates (High, Medium-High, Medium, etc.); if you select Policies or Preferences, the second dropdown lets you select any of the five standard zones or five lockdown zones.  (See this post for more information about all those zones.)

Click “OK” on the “Pick items…” dialog, and the selected settings will be rendered in the list view.  Items that are present in both columns but with different values will be highlighted in yellow.  Items that are present only in one column will be grayed in the other column.

Additional Features

To find a particular item with a partial text search, press Ctrl+F (or the “binoculars” toolbar dropdown).  The text search is case-insensitive and searches in all columns from the currently-selected row down.  Press F3 to repeat the last search from the current location.

Enter a URL in the text area in the toolbar and click “Map URL to Zone”:  IE Zone Comparer will tell you in what security zone IE would render that URL.

The Help/About toolbar button includes some helpful links for more information about IE security zones and URL actions.

Some Example scenarios for the IE Zone Comparer

• View effective settings for a particular zone.  E.g., something isn’t working correctly on a page that is rendered in the Intranet zone.  If user settings are being ignored, select Machine Policies / Intranet and Machine Preferences / Intranet.  Policies override preferences; where no policy is set, the machine preferences will apply.
• Compare the relative security settings of the Intranet zone vs. the Trusted Sites zone (see screenshot above).
• Seeing exactly what changes when you transition from the Locked-Down Local Machine Zone to the regular Local Machine Zone.  (Description here.)
• Compare Machine Policies for a zone to the policies mandated by FDCC Q1 2009.
• View the settings that are applied by a given template, and compare those settings to another template or to an existing zone to see whether it has been modified from that template.
• Compare the effective settings of the Locked-Down Local Machine Zone (LMZL) to Local Machine Zone, to see what becomes enabled when the user clicks through the information bar.
• Compare user preferences for a zone to the machine preferences for the same zone.  (They should be the same; if they are not, then results may change when the “use only machine settings” policy is applied.)

[November 7, 2009:  An updated version, IEZoneAnalyzer, has been posted that shows the effective settings for a selected zone and where each of the settings are established.]

The Case of the Unexplained Installation Failure (and an ill-advised registry hack)

Since Mark Russinovich hasn’t trademarked his “Case of the Unexplained…” series, I’m appropriating the title to describe the results of some troubleshooting I did for a customer.  The root cause turned out to be a widely-adopted but ill-advised registry hack that many organizations have built into their standard desktop images.  If you’re not interested in the troubleshooting steps, skip ahead past the nerd content here and just read the Analysis.  [Spoiler:  it’s about the Autorun.inf “SYS:DoesNotExist” registry hack.]

The Case

The customer has Kodak scanners that come with CDs containing the required software.  When the admin inserted the CD, Autorun didn’t quite work correctly – the Autorun dialog appeared but did not show the Autoplay option to install the software.  So the admin opened the folder in Explorer and started autorun.exe to start the installation.  Shortly after approving the User Account Control elevation request, the admin saw an error message with a strange title that looked like the installer was performing an incorrect OS version check:

App install error message

The Troubleshooting

I figured that the author of the installation program had assumed that since Windows XP was so perfect that Microsoft would never need to release another version of Windows, there was no reason to check for newer versions.  I applied the WinXP compatibility mode (which among other things lies to the program about what the OS version actually is) and tried again.  It failed in exactly the same way.  What’s more, the installation worked perfectly well on freshly installed copies of Windows Vista that didn’t have the organization’s policies applied to it.  Ah – so it’s not a Vista issue, there’s something in the policies!

I started Process Monitor, and ran the installation program again to the point of the error message and then stopped the Procmon trace.  I dragged the Procmon crosshairs toolbar icon over the error message to apply a filter to show only events involving the window owner’s process (setup.exe).

Because of the “0” in the title in the error message, I thought the problem might be due to the program searching for something and not finding it, so I right-clicked on items in the Result column and excluded events with result codes I figured wouldn’t be interesting:  SUCCESS, FAST IO DISALLOWED, FILE LOCKED WITH ONLY READERS, REPARSE, BUFFER OVERFLOW, and END OF FILE.  (I usually exclude results that I want to filter out rather than include results that might be interesting because it’s easy to miss some when setting “include” rules.)

When I looked at the remaining entries, one thing that quickly stood out was the name “DoesNotExist” appearing in path names near the end of the results.  I used Procmon’s highlighting feature to make them stand out in the context of surrounding events.

Because the surrounding context didn’t give me an idea of what had happened immediately prior to these failed searches, I took advantage of Procmon’s non-destructive filtering and removed the filter rule that excluded SUCCESS results.  As you can see in the screenshot, there had been a bunch of file accesses to D:\setup.ini and then a few to D:\autorun.inf before the attempted registry access to HKLM\Software\DoesNotExist\Info.

 

 

I opened the event properties for the first RegOpenKey event and looked at the call stack to get an idea of how and why setup.exe was trying to open that key.  Line 12 of the stack showed that the randomly-named component of the setup program was calling into GetPrivateProfileStringA, which led (in line 7) to an attempt to open a registry key.

GetPrivateProfileString is one of the APIs that Windows programmers can use to read from files that are formatted like the old .ini files from 16-bit Windows.  And as its documentation points out, those accesses can be redirected to the registry with an IniFileMapping.  I located the IniFileMapping that redirected autorun.inf to “DoesNotExist”, deleted it, rebooted, and the installation then worked correctly.

IniFileMapping entry redirecting Autorun.inf to a non-existent registry key

The Analysis

What is IniFileMapping?

IniFileMapping has been part of Windows since NT 3.1.  When programs use the ini-file APIs to access files, an IniFileMapping entry can redirect the access to the machine or user registry (HKLM or HKCU).  IniFileMapping was designed to help older apps that used .ini files to use the registry instead, to take advantage of the scalability benefits and to enable multiple users to have their own copies of settings instead of sharing a single ini file.

What is Autorun.inf?

When a removable disk, such as a CD or a USB drive, is inserted and Windows detects the new disk, Windows Explorer checks for an Autorun.inf file in the root folder of the drive.  The Autorun.inf is a text file formatted as an .ini file (that is, section names in square brackets, name=value pairs within each section).  It can include entries which tell Explorer what icon to display for the drive and a default Autoplay action to offer to the user, or in some cases, the program can just begin running.  This is the mechanism that allows a program installation to automatically start just by inserting a CD.  There are registry settings and group policies that can control whether and how Autorun and Autoplay work.  (That link also describes the distinction between Autorun and Autoplay.)

A problem with Autoplay is that by default it has also been applied to writable drives such as thumbdrives.  Worms like Conficker were able to propagate through such devices by writing an Autorun.inf and a copy of itself to the drive.  The malware could then infect other computers simply by inserting the drive.  That was compounded by a bug in the implementation of the settings that were supposed to disable Autoplay.  That bug has since been fixed.  Furthermore, updated Windows systems now have Autoplay disabled by default for writable drives.  Autorun and Autoplay still work for CDs and DVDs, as the threat of worm propagation through that avenue is much smaller and (at this time) does not outweigh the benefits.

Why does this computer have an IniFileMapping for Autorun.inf?

A couple of years ago, a blog post described a clever trick to disable Autoplay for all drives.  The trick leveraged the fact that Autorun.inf is formatted as an ini file and that Explorer uses the ini file APIs to read it.  By creating an IniFileMapping for Autorun.inf that redirects access to a non-existent registry key, Autoplay entries cannot be read.  The author asserted that the only negative effect is that users must browse for the file to execute.  As more malware began using writable removable drives as a propagation mechanism, CERT and other security-conscious organizations began recommending this trick, adding the assertion that “This setting appears to disable Autorun behaviors without causing other negative side effects.”  Since then, the setting has been mandated as part of the standard image for many organizations.

Why did this application install fail?

It turns out that the Autorun.inf on Kodak’s installation CD contained much more than just Autoplay entries:

[autorun]
open=autorun.exe

[Info]
Dialog=Kodak i610/i620/i640/i660 Scanner
Model=600
ModelDir=kds_i600
ProgramGroup=i610,i620,i640,i660

[Versions]
CD=04040000
FIRMWARE=04000300
ISISDRIVER=2.0.10711.12001
ISISTOOLKIT=57.0.260.2124
KDSMM=01090000
PKG=02010000
SVT=06100000
TWAIN=09250500

[Install]

[SUPPORTEDOSES]
WIN=WINVISTA WINXP WIN2K

[REQUIREDSPS]
WINXP=1
WIN2K=3

Kodak uses the Autorun.inf not only for Autoplay but as a general-purpose ini file containing configuration settings for the installation program.  The installation program of course uses standard APIs to read the file, but the IniFileMapping redirects to a non-existent registry location, causing the installer to fail.  It needs to be said here that what Kodak is doing is perfectly legitimate.  There are no guidelines that say that the Autorun.inf cannot contain other application specific settings.

Could the customer have worked around the problem by copying the CD content to the hard drive and running it from there?  No.  The IniFileMapping setting applies to any file called Autorun.inf no matter where it is.

The bottom line is that the installation failed because the assurances of no “negative side effects” were not backed with extensive compatibility testing, and denies legitimate usage scenarios.

Recommendation

Customers who want to block Autoplay should use supported mechanisms rather than relatively untested hacks that can end up causing unintended side effects.  I’ve seen plenty of cases where a non-standard setting that seems to many to be perfectly safe turns out to have serious repercussions that aren’t discovered for years.  (That sort of thing led to the publishing of KB article 885409.)

Source code for New and Updated Local Group Policy utilities

Visual Studio 2008 source and project files for the new ImportRegPol utility and the updated Set_FDCC_LGPO and Apply_LGPO_Delta utilities for managing Local Group Policy Objects.

Note that these are all now Visual Studio 2008 projects.

[Update Jan 15 2010:  new versions released -- see the LGPO Utilities page]

New and Updated Local Group Policy Utilities

A customer requested an addition to the local group policy toolset posted on the FDCC blog.  While working on the new utility, I needed to upgrade the other two.  The full set is attached to this post, with documentation.  The source code for all of them is attached to a separate post.

The new utility, ImportRegPol, takes a registry policy file (registry.pol) as input.  It can import its contents into the local group policy of the local computer (Computer or User configuration), or simply read it and output Notepad-editable text that can be consumed by Apply_LGPO_Delta.

While working on it, I discovered and corrected subtle shortcomings in Set_FDCC_LGPO and Apply_LGPO_Delta.  The main shortcoming had to do with when a value or set of registry policy values were to be deleted:  if the settings were present when Set_FDCC_LGPO or Apply_LGPO_Delta was run, they would be deleted, but those deletion “commands” were not saved in the policy store.  So, if the settings were to be reintroduced, gpupdate from local policy would not remove them.  The new implementations insert the deletion “commands” into the policy store so that they can be applied whenever policy refreshes.  This required extending the input file syntax for Apply_LGPO_Delta and the log file output for Set_FDCC_LGPO, both of which have been bumped to v2.0.

While I was at it, I upgraded those utilities to Visual Studio 2008 and enabled ASLR and DEP.  In addition, the new version of Apply_LGPO_Delta does not perform an OS check, so it is no longer restricted only to Windows XP and Vista, and will run on any supported version of Windows.  Set_FDCC_LGPO still runs only on XP (SP2 or higher) or Vista (RTM or higher), because NIST hasn’t defined FDCC settings for any other versions of Windows.

Here is more information on the new ImportRegPol utility:

ImportRegPol

ImportRegPol is a non-interactive tool that imports the settings from a Registry Policy (registry.pol) file into the Computer or User configuration of the local group policy of the current computer.  It can also parse a registry.pol file and produce an editable text file that can be consumed by Apply_LGPO_Delta v2.0.

Introduction

Administrators frequently apply policies by copying registry.pol files into the Group Policy folders.  This technique is not supported by Microsoft, and has the unfortunate side effect of destroying any previously existing policies.  ImportRegPol reads the reference policy file and uses supported application programming interfaces (APIs) to add settings to local policy.

The format of registry policy files is a documented, binary file format, normally produced by Group Policy editors such as GpEdit.msc.  However, there aren’t any good viewers or editors for directly manipulating those files.  For this reason, the Apply_LGPO_Delta utility uses a custom, Notepad-editable text file format to define specific changes to apply to local group policy.  The log file format produced by ImportRegPol is compatible with Apply_LGPO_Delta v2.0.  ImportRegPol can be run in a “parse-only” mode to read a registry.pol file and produce an equivalent input for Apply_LGPO_Delta.

The utility requires administrative rights to import policies, but does not require administrator rights for parse-only mode.  Note that the in-use registry.pol files in the GroupPolicy folders can be used for input only in parse-only mode.

Command line syntax and usage:

The ImportRegPol command line syntax is described below.  All parameters are case-insensitive.  The command line must include -m or -u followed by the absolute or relative path to a registry policy file.  All other parameters are optional.

ImportRegPol.exe –m|-u path\registry.pol [/parseOnly] [/log LogFile] [/error ErrorLogFile] [/boot]

-m path\registry.pol   [for Computer configuration] or

-u path\registry.pol   [for User configuration]

                        Path\registry.pol specifies the absolute or relative path to the input registry policy file (which does not need to be named “registry.pol”).

/parseOnly             Reads and validates the input file but does not make changes to local group policy.  In conjunction with the /log option, can be used to convert a registry policy file to an input file for Apply_LGPO_Delta.

/log LogFile           Writes detailed results to a log file.  If this option is not specified, output is not logged nor displayed.  The logged results for the registry policy settings can be used as input for Apply_LGPO_Delta.

/error ErrorLogFile   Writes error information to a log file.  If this option is not specified, error information is displayed in a message box dialog.

/boot                  Reboots the computer when done.

This utility is not a console app, so you won’t see a console window appear, and if you start it from a CMD prompt, it will run in the background – CMD won’t wait for it to complete.  You can check in TaskMgr to see when it completes.  If you want CMD to wait for ImportRegPol to complete, run the utility with "start /wait".

[Update Jan 15 2010:  new versions released -- see the LGPO Utilities page]

FDCC Vista Application Development Requirements

Overview

NOTE: This entry only focuses on the Windows Vista version of the FDCC and desktop applications.

Since its infancy, common themes have emerged which have delayed or prevented enterprise customers from deploying the FDCC. By the 80/20 rule, the two most common problems, in order, are:

1. Data and Settings Management

2. Application Installation

Customers have encountered other, smaller issues. But these two will cover 80% of the problems faced by applications when implementing the FDCC.

This entry will discuss the background of these items and how to best develop your application for the FDCC. It is primarily intended for developers, but system administrators can benefit too because some features of Windows will be discussed that can make your life easier.

This entry does not discuss UAC Virtualization. It assumes you are developing applications that will function entirely as a normal user.

Before we dive in, let’s discuss a little background and the purpose of the FDCC.

Why the FDCC?

The spirit of the FDCC is to provide a standard operating system image and settings, a common set of applications, and firewall for a non-privileged user community. This is the best way to secure an enterprise and ensure fundamental system integrity while reducing costs.

Users cannot be allowed unrestricted access to a system. There is no technical or business reason users should have elevated privileges to browse the internet, check email, or create and modify documents. Doing so provides an easy opportunity for malware to steal, destroy, or falsify data.

The foundation of the FDCC is Microsoft Windows Vista with NTFS. This is great news for those who have invested time and effort learning how to develop on the Windows platform. If you have developed on Windows in the private sector/commercial world, then developing on the FDCC will be an easy transition.

The FDCC, and Windows in general, is a system designed for multiple users and to isolate the actions of multiple users. Non-elevated users can only write to their own profile. They are not allowed to:

· Make system-wide changes

· View or modify another user’s profile

· Write or modify directories owned by the operating system containing binaries such as EXE’s or DLL’s

This helps keep any unintentional and/or malicious activity by one user from affecting other users of a system and spreading across the enterprise.

Unfortunately, MCS has worked with many applications that modify the default permissions and leave a machine more vulnerable to attack. Security can be completely undone by one application making a seemingly minor change.

Your job as a developer is to make sure you follow these best practices to maintain this default security.

Know your Users

The target audience for FDCC applications is no longer the workgroup. Gone are the days when you could assume a system administrator could physically visit the machines of your user community and install and configure application. Developers must make every effort to make sure their application can be deployed and configured in an enterprise environment with hundreds, thousands, or myriads of users.

Administrators are users too and first impressions last forever. Often the first experiences administrators have with applications are when they install the software on client machines. This experience can either be a good one or bad. The requirements put forth in this document ensure that administrators have all of the tools they need to do their job.

Data and Settings Management

Windows Vista provides the infrastructure to separate user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:

· Applications do not fail when run by non-privileged users

· Administrators or users can easily back up data and settings without needing to backup application or operating system files

· Multiple users can share a single computer, each with his or her own preferences and settings

· System administrators can enable Folder Redirection

· Applications are less likely to prevent Fast User Switching from operating correctly and efficiently

· Administrators can easily migrate user data when users get a new computer

History

Many applications make assumptions that their users would have administrative privileges and thus often try to write to protected areas of the operating system. Most commonly, these protected areas are the Program Files folder or HKLM. More generally, these areas include any resource in which normal users did not have write/modify access. Thus, on Windows XP many applications reported “access denied” error messages. Windows Vista introduced UAC Virtualization, but users often have no idea where the target redirection occurred. What’s more is that UAC Virtualization may be turned off in some organizations. If this occurs, applications commonly report “access denied” error messages just as they would were they running on Windows XP.

Several organizations maintained separate, logical drives for applications and data. Thus, it was common to find all application binaries installed on the C: drive and then a folder would be set up on the D: drive for user-created data. The idea was that the data would be safe on the D: drive if the C: drive ever crashed.

Also commonly found, were applications that installed custom directories on the root of the C: drive that contained application binaries and user-created data. The argument in favor of this practice was that applications and data could easily be migrated to new machines simply by backing up the directory on the old machine, and restoring it on the new on.

All of these scenarios remove flexibility from the system administrators and make network management more difficult. They raise the total cost of ownership for enterprises because:

1. Tools like the User State Migration Tool migrate user-created data, but it takes time and resources to develop and test each of these extensions. Often, several trial-and-error attempts must be made before it’s considered ready for production. Inevitably, something gets missed.

2. Administrators no longer have the flexibility to us folder redirection for user-created data.

3. While having the application isolate data into its own custom directory enabled users to share data, the negative is that this approach is a one-way street. It becomes difficult to separate data so that only certain users had access to it. It also makes using the application inside Terminal Services sessions practically impossible without major re-writing.

The following requirements will ensure that administrators have maximum flexibility and will help reduce their workload and allow them to administer by exception.

User-Created Data

User-created data is anything a user can store or retrieve at a later time. Obvious examples are Word, Excel, or PowerPoint documents. User-create files must be stored in the Documents folder or subfolder. The default Documents folder location for a typical Vista installation is C:\Users\<username>\Documents, but paths should never be hard-coded. Calling the Common Item Dialog will default to the Documents folder. Windows Vista also provides direct access to the Documents folder using the SHGetKnownFolderPath function passing in FOLDERID_Documents. For example:

PWSTR pszDocFolder;
SHGetKnownFolderPath(FOLDERID_Documents, 0, NULL, &pszDocFolder);
CoTaskMemFree(pszDocFolder);

On a typical installation of Windows Vista pszDocFolder would contain the string “C:\Users\<username>\Documents”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.MyDocuments parameter.

The benefits of using the Documents folder as the default location for data storage are:

· All users (including those with restricted account types) have write access to this location

· Users have one familiar place to organize and store all their data

· Data sharing is facilitated between applications because all applications using Common Item Dialog can easily access the Documents folder

· The Documents folder is an abstracted location and can be redirected to the network transparently by an administrator

· The Documents folder is available on the Start menu

Application-Created Data

Application-created data is used by the application to store application state, user preference, and temp files, etc. This type of data is typically hidden from users.

By storing this application-specific data in one of the several valid locations, you make it possible for multiple people to use the same computer without corrupting or improperly modifying each other’s data. The specification provides several valid locations and you are free to choose the location that works best for your needs.

A clear benefit to the developer is that can actually result in fewer lines of code. SHGetKnownFolderPath enables you to determine the correct location in which to store the user’s data and the user-specific application data.

Classifying and storing application data according to the guidelines in this requirement provides these benefits:

· It enables multiple users to share a computer and helps enable Fast User Switching.

· It enables business-related operations such as roaming, off-line storage, and allowing the operating system and its applications to be secured.

· It ensures a consistent and abstracted location for user data, enforces per-user separation of application data.

· It is one of the key factors in enabling remote use of the application.

This section identifies the valid file folders and the valid registry locations that applications must use for this data, and gives guidance on how to choose which of these locations are best used in different circumstances. The choice of valid locations to use is left to the software developer.

Classify application data into the following categories:

· Per user, roaming

· Per user, non-roaming

· Per computer (non-user specific and non-roaming)

NOTE There may be more than one category for the different application data stored by your application.

It is best to use application data file folders rather than the registry for storing application data in excess of 64K. The registry is an acceptable choice for small amounts of data. At installation time, try to store less than a total of 128K across HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM).

To comply with this specification, store application data files appropriately as either common or per-user. That is:

· In a subfolder of either the common application folder (identified by FOLDERID_ProgramData), or

· In the user profile folders: application data (FOLDERID_RoamingAppData) or local application data (FOLDERID_LocalAppData).

The subfolder to create to store user data files in is:
[company name]\[product name]\[version].

Using the Registry

Applications may also use the registry to store read/write application and configuration data.

· The HKCU registry hive is appropriate for storing small amounts of data (approximately 64K) and for policy settings that are per user.

· Avoid writing to HKLM during runtime, because limited users have read-only access to the entire HKLM tree by default. In addition, HKLM does not support roaming.

· Larger, file-based data should be placed in an application data folder. For example, Internet Explorer’s Temporary Internet Cache is stored within the file system of the user’s profile and not in the registry.

· At installation time, the application should not store more than a total of 128K across HKCU and HKLM.
Note that HKEY_CLASSES_ROOT is excluded.

Using Application Data Folders

Once you have decided how to classify your data, you can use SHGetKnownFolderPath to retrieve the corresponding folder locations.

The KNOWNFOLDERID values described here provide a consistent, unified way to access the physical paths to the desired folder locations, independent of the operating system. The preferred API is SHGetKnownFolderPath. To access the path for application data, applications should call SHGetKnownFolderPath with the appropriate KNOWNFOLDERID and then append [company name]\[product name]\[version] to the returned path. Specifically:

PWSTR pszAppData;
SHGetKnownFolderPath(
FOLDERID_RoamingAppData, 0, NULL, & pszAppData);
CoTaskMemFree(pszAppData);

On a typical installation of Windows Vista pszAppData would contain the string “C:\Users\<username>\AppData\Roaming”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.ApplicationData parameter.

When storing application data in the user profile, applications must use the following hierarchy under the Application Data file structure:

FOLDERID_RoamingAppData\
  [Company or Organization Name]\
    [Product Name]\
      [Version]\
        [File or Folder]

Data Type	KNOWNFOLDERID	Folder Location
Per user, roaming	FOLDERID_RoamingAppData	[user profile]\AppData\Roaming
Per user, non-roaming	FOLDERID_LocalAppData	[user profile]\AppData\Local
Per computer (non-user specific and non-roaming)	FOLDERID_ProgramData	C:\ProgramData

To comply with this specification, applications must classify and store data appropriately as either common or per-user. That is, either FOLDER_ProgramData or one of the user profiles: FOLDERID_RoamingAppData or FOLDERID_LocalAppData.

FOLDERID_RoamingAppData

This folder will be enabled for roaming with the user profile. Use this folder to store all user-specific application preferences. For example, if a user can specify a custom dictionary to be used in the application, you would store it here. That way, if a user roams from computer to computer, the dictionary will roam with him or her. This also allows other users to have their own custom dictionaries.

FOLDERID_LocalAppData

This folder is for application data that does not roam. As it is still part of the User profile, this is still per-user information. Application data that is computer-dependent, such as user-specified monitor resolution, must be stored here.

This data must not roam because different computers are likely to have different monitors. In addition, large blocks of data that can easily be recreated and temporary files must be placed here to minimize download time that is incurred when roaming.

EXAMPLE Internet Explorer keeps its cache of downloaded .html/.gif pages here so that they don’t roam with the user. However, the smaller cookie and history lists are stored in FOLDERID_RoamingAppData so that they do roam.

FOLDERID_ProgramData

This folder should be used for application data that is not user specific. Note that a limited user will only have read privilege for files in this folder, except for the files that user created. If users need to have write access to the common files, then during installation the application must create a sub-folder of FOLDERID_ProgramData with “Modify” privilege for appropriate user groups.

EXAMPLE An application may store a spell-check dictionary, a database of clip art or a log file in the FOLDERID_ProgramData folder. This information will not roam and is available to anyone using the computer.

Additional Considerations

· Files may be shared in the application data (FOLDERID_LocalAppData, FOLDERID_LocalAppDataLow or FOLDERID_RoamingAppData) folders. Multiple computers may use them simultaneously with different instances of the application. The data may also be used by multiple applications, for example, applications in a productivity suite.
Applications should get a write exclusive on the file only when absolutely necessary. For example, applications using CreateFile should only specify GENERIC_WRITE when a write is required, but they should always set FILE_SHARE_READ.

· Paths returned by SHGetFolderPath are valid Win32 file system names that may contain spaces and may be in the universal naming convention (UNC) format.

· PathAppend() and PathCombine() APIs can be used to concatenate the relative path information onto the paths returned by SHGetFolderPath. For example:
PathAppend(szAppData, "Company\Product\File.txt")

· By default, all users can write to the Users\Public\Documents location (FOLDERID_PublicDocuments).

Application Installation

The best way to package applications is using the Windows Installer format. Windows Installer is the native application installation engine in Windows Vista. It provides the following benefits:

· Applications can be inventoried using Windows Installer

· System administrators can selectively change how and which features will be installed

· Applications have the ability to self-heal

· It enables applications to separate per-user and per-machine installation tasks

· Applications can provide silent or unattended capabilities often with little effort on the developers part

· It enables system administrators to easily choose how the app is deployed (Group Policy Installation or Configuration Manager installation)

· A properly formatted MSI package is transactional. It either completely installs or completely fails. It never leaves the system in an unknown state.

· It automatically supports UAC

· There is already a large ecosystem of applications packaged in the Windows Installer format. Thus, the learning curve is minimal or non-existent for most system administrators.

See the following links for more information on Windows Installer:

· Overview of the Windows Installer Technology

· Developer Story Windows Installer

History

Once upon a time, it was common to find organizations with administrators running around the office from machine to machine, installing and configuring applications. Many lines of business (LOB) applications were limited to a finite set of known users and so it was understandable to train a few people how to administer them. They were built with enough functionality to meet the needs of the end user, but the burden of installing and configuring the applications was largely left to the administrators by following a long series of manual steps on each user’s desktop. The unfortunate reality is that creating a solid installation package was mostly an afterthought for many application developers.

The worst offenders had no installation package or the installation package was nothing more than a scripted xcopy. Administrators were instructed to create a directory, copy EXE’s and DLL’s, create registry keys and shortcuts before the application could be used. Any missed step or instruction not followed perfectly lead to a partially functioning application or, worse, a non-functioning application. Repeatability of the application installation was low and configuration management became more difficult. But even if an administrator got an application installed properly, there were often other difficulties running the apps.

Many applications stored user-created data and application data in the same directory as the application directory. If these applications were installed to Program Files, normal users were denied write and modify access. Thus, even if users weren’t responsible for installing and/or configuring their applications, they were still often granted elevated privileges because some applications simply would not run otherwise. But because users had full control over their PC’s, it created an unmanaged situation and administrators often had no idea how each machine was configured. Worst of all, users can easily download – without even realizing it—malware. This is an invitation to hackers and has historically been the cause of several security breaches in enterprise networks.

Many applications are also commonly installed to non-standard locations on the root of the hard drive, such as C:\AccountingApp. This was thought to solve the problem of giving users administrative privileges because users were able to read/write/modify. Plus some developers argued that it made migration from one machine to the next easier because a single directory could be copied from the source machine to the target machine. But it presented other problems.

Any user with write/modify access to the application folder would be able to replace the application binaries. But remember – Windows and the FDCC are designed to isolate multiple users and their actions. Thus, allowing users write/modify permissions to binaries shared by multiple users could allow someone with malicious intent to view or modify another user’s profile or make system-wide changes. More details and consequences of which can be found in the Changing access control on folders vs. files post.

In addition to being a security vulnerability, this approach also made it more difficult when users were upgraded to a new machine and data had to be migrated. Many development teams reasoned that application data is all stored in one place so it’s easy for an administrator to a folder from one machine to the next. True, but only if the administrator has to do it one time. And it completely ignores the security aspect. But security aside for the moment: what happens when there are hundreds or even thousands of machines and/or users? Administrators must rely on tools to help them migrate data like this.

Tools like the User State Migration Tool automatically migrate data for several hundreds of applications. And it is extensible so that administrators can migrate LOB apps. But it takes a lot of resources to configure USMT correctly. So what happens when there are hundreds or even thousands of applications?

Installation Directory

Applications must always target the Program Files folder by default. Applications that install to a subdirectory of this folder inherit the restricted permissions from the parent by default. Normal users are given read and execute permissions to application binaries. But they are not allowed write or modify permissions.

FDCC and Internet Explorer 7, Part 3 – Protected Mode

This is the [long-delayed] third installment in a series discussing various issues regarding the intersection of Microsoft Internet Explorer 7 and the Federal Desktop Core Configuration (FDCC). The FDCC bears close resemblance to Microsoft’s security guidance for Windows XP and Windows Vista, so this series will be of interest to any customers who are locking down Windows and Internet Explorer.

The first post in this series covered IE’s security zones, changes made to “Trusted Sites” in IE7, preferences vs. policies, templates, and the “locked down” zones. The second post discussed the impact of FDCC-mandated policies on typical Internet Explorer users. This post discusses the impact of Protected Mode on Windows Vista.

The two main issues covered here are:

1. While Protected Mode improves security against web-based threats, it can cause some application compatibility problems with line of business web applications.

2. There is a bug in the default configuration for IE7 that can inadvertently enable Protected Mode in the Computer zone, which can break more stuff.

Windows Vista enhanced its security infrastructure with Mandatory Integrity Control, which makes Internet Explorer’s “Protected Mode” possible. To summarize, IE in Protected Mode runs in a process with a constrained security context that prevents the process from modifying most areas of the file system and registry, including those areas that the user is normally allowed to modify, such as the user’s Startup folder. Protected Mode is intended to serve as a defense in depth measure, so that if malware from the internet manages to exploit a browser vulnerability, it will be much harder for the attacker to make changes to the user’s system.

Protected Mode is a per-zone setting. It is enabled by default for the Internet and Restricted Sites zones, disabled for the Trusted Sites and Local Machine (a.k.a., “Computer”) zone. The Intranet zone has Protected Mode enabled by default in IE7, but disabled by default in IE8. I’ll explain that change in a moment.

With Internet Explorer 7, all the tabs within a window frame are managed by a single process. Because Protected Mode is an attribute of the process, everything displayed within a particular IE7 window is either Protected Mode ON or Protected Mode OFF. So if the user navigates from a zone where PM is enabled to one where PM is disabled (or vice versa), IE7 needs to open a new window, and displays this dialog:

This is admittedly not the greatest experience from the user’s perspective. Internet Explorer 8 was re-architected so that individual tabs within a window frame can be managed by separate processes which can be swapped out as needed, so navigating between PM-enabled and PM-disabled is now seamless.

The reason that Protected Mode was enabled for the Intranet zone in IE7 was not for any security benefit. The Intranet zone, after all, is the most permissive of the zones, allowing the use of more browser-based programming techniques than do the other zones. For example, the pop-up blocker is disabled only in the Intranet zone. The reason that IE7 turns on Protected Mode for the Intranet zone is only to avoid having to switch windows when navigating between the Internet and Intranet zones, which the designers assumed would be the most used zones in the enterprise.

As long as the web app you’re using uses only standard HTML, DHTML, AJAX, etc., it usually doesn’t matter whether it is in Protected Mode or not. But if you have mobile code (e.g., ActiveX or Java) that expects to be able to write to the file system or registry, Protected Mode can cause your app not to work as expected. Since custom ActiveX and Java is common with line of business (LOB) web applications, this can lead to a significant number of application compatibility issues.

When this is the case, it is worth considering disabling Protected Mode for the Intranet zone. It is possible to rewrite the custom code to work in Protected Mode, for example by leveraging external broker applications as described in the MSDN article, Understanding and Working in Protected Mode Internet Explorer. However, this can be complex, time-consuming and expensive. Given that IE8 already disables Protected Mode for the Intranet zone, it is far simpler just to disable it for IE7 as well. Upgrading to IE8 is another alternative worth considering.

Also, if the sites that users spend the majority of their time in are in the Intranet and Trusted Sites zones, turning off Protected Mode for the Intranet zone reduces the number of window switches as well.

Having said that, let me make very clear that it is strongly recommended that Protected Mode always remain enabled in the Internet and Restricted Sites zones. If you have external sites that are business-critical and that fail with Protected Mode (e.g., due to use of Java), they should be added to the Trusted Sites zone.

Here is how to disable Protected Mode in the Intranet zone through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Intranet Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)

Bug in Default Settings for Protected Mode for the Local Machine Zone

There are numerous places where IE security zones can be configured: for each of the five zones, there are machine-wide policies and preferences; per-user policies and preferences; and then corresponding “lockdown” zones for each of those, of which the most important is the Local Machine Zone Lockdown (LMZL). For more information about these topics, see FDCC and Internet Explorer 7, Part 1: Security Zones.

Protected Mode is not intended to be used in the Local Machine (a.k.a., Computer) zone, and it is set to Disabled in all the places where it can be configured – with one exception. Due to an oversight, the default configuration of IE7 enables Protected Mode in the machine preferences for the LMZL. As described in Part 1 of this series, machine preferences normally have no effect – unless the “Security Zones: Use only machine settings” Group Policy setting is enabled, as it is in the FDCC, and in Microsoft’s security guidance for Windows. The Protected Mode setting remains in effect when transitioning from the Locked-Down LMZ to the normal LMZ, since unlike the other zone settings it cannot be changed without switching to another process.

As described in the previous section, Protected Mode can cause app breakage when the app expects to be able to write to the file system or registry. Common examples we’ve seen are failures with “print preview” and similar functionality where the preview content has been written to and then opened from the local hard drive.

When IE8 is installed, the setting is corrected. For IE7, the change has to be applied directly. Here are the specifics:

Key: HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ Lockdown_Zones \ 0

Value name: 2500

Change the value from 0 to 3.

You can also fix the problem through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Locked-Down Local Machine Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)

Set_FDCC_LGPO.exe v1.06, Visual C++ project sources

Visual Studio 2005 project files and source code for Set_FDCC_LGPO.exe v1.06 is attached to this blog post.

[Removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Set_FDCC_LGPO updated: v1.06

Set_FDCC_LGPO has been updated to reflect the updated GPO content on NIST's download page.  The FDCC settings have not changed.  The updates contain only corrections to the downloads to more closely adhere to the FDCC settings.

The updated Set_FDCC_LGPO is attached to this blog post.  (This time I also remembered to include the readme.htm in the zip file.)  The updated Visual C++ project sources are here.

To recap:  Set_FDCC_LGPO is a non-interactive tool that applies the Q1 2009 FDCC desktop policy settings from NIST to local group policy and optionally to the security settings of the computer as well.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Apply_LGPO_Delta v1.01, source code

Visual Studio 2005 project and source code files for Apply_LGPO_Delta v1.01 is attached to this blog post.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Apply_LGPO_Delta updated, v1.01

Apply_LGPO_Delta is a utility for automating the management of local group policy -- administrative templates and security templates.  First posted here, it has been updated with the same fix that was applied to Set_FDCC_LGPO to prevent the 0x80070020 sharing-violation error from occurring.

Documentation is in the download.  The sample starter files have been updated, including the addition of a security template you can use to revert the file system permissions changes that FDCC mandates on XP.

Updated source code is here.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]