FDCC and Internet Explorer 7, Part 2 – Impact on Users
This is the second 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. This post will discuss the impact of FDCC-mandated policies on typical Internet Explorer users:
Installing ActiveX
Viewing or changing security zone settings
FIPS – “System cryptography: Use FIPS compliant algorithms…”
Prevent ignoring certificate errors
Java, and Java Permissions
User goodies
Impact of FDCC-mandated policies on typical IE users
Installing ActiveX
The single most impactful and valuable aspect of the FDCC is its mandate that users not have administrative rights on their computers. This single requirement is what provides the greatest security and cost-reduction benefits of the FDCC. Without this part of the mandate, the value of the rest of the required policies is minimal. (Note that the Power Users group on Windows XP is an admin-equivalent group. Users should not be members of this group, nor of Backup Operators.)
It must be emphasized that while FDCC expressly forbids typical users from running with elevated privileges, as of this writing there is no Group Policy setting to enforce it, nor any scanning tools that validate it. Nevertheless, it is part of the FDCC mandate, and agencies are required to follow it.
For Internet Explorer users, the most noticeable result of running as non-admin is that they can no longer install ActiveX controls. Non-admin users do not even get prompted when a site they have browsed to wants to install an ActiveX.
The deployment model for ActiveX has traditionally been on-demand, and performed by Internet Explorer itself. When a user browses to a web page that uses an ActiveX control, the page can specify the location from which the control can be downloaded and the minimum version required. Internet Explorer checks whether the required or a newer version is installed; if not (and if the user has the necessary rights), the user will be prompted to install or upgrade the control. The installation is performed by Internet Explorer, which runs in the security context of the logged-on user. Installing ActiveX typically involves copying files into system-wide locations (%windir%\Downloaded Program Files), and registering settings in system-wide registry locations (HKEY_CLASSES_ROOT, which usually maps to HKEY_LOCAL_MACHINE\Software\Classes). Non-admin users have never been allowed to do this, and so Internet Explorer long ago added a check for necessary rights so that non-admin users wouldn’t get prompted for an install they couldn’t perform.
For organizations that have used ActiveX for web-based line of business (LOB) web applications, this creates some challenges. The ActiveX controls cannot be deployed in the traditional manner. There are several ways to manage these challenges:
· On Windows Vista, the ActiveX Installer Service can be configured via Group Policy to allow non-admin users to install ActiveX controls from designated sites.
· ActiveX controls can be repackaged to be deployed through Active Directory Group Policy, SMS or another enterprise management system.
· Internet Explorer 8 (now at Beta 2) allows an ActiveX control to be marked so that it can be installed per-user rather than per-machine, and not require admin rights to install.
· Retire the ActiveX and reimplement the required functionality using AJAX, .NET ClickOnce or another technology that doesn’t require client admin rights.
More information about the ActiveX Installer Service (a.k.a., “AxIS”) can be found here:
· The ActiveX Installer Service in Windows Vista (TechNet Magazine)
· Implementing and Administering the ActiveX Installer Service
· ActiveX Installer Service Discussion and Video (circa Windows Vista RC1)
· KB 951585 (describes a hotfix that may be needed for some environments)
Technical information about Internet Explorer 8 can be found here:
· Internet Explorer 8 Beta 1 Whitepapers (including Non-Admin ActiveX Controls)
Viewing or changing security zone settings
Another important aspect of FDCC (or of any locked down configuration, for that matter) is that end users make many fewer trust or security decisions. These decisions are made instead by trained security professionals – or at least by designated system administrators who hopefully have more than just a tenuous grip on IT security concepts and issues.
Included in this set of decisions is how much trust to place in various web sites. On unrestricted computers, users can choose which sites to treat as “Trusted site” or “Restricted sites”, and determine what sites should be treated as part of the “Local intranet”. Users are also able to change individual security settings for each of these zones, or apply a different template to a zone (e.g., set “Trusted sites” to the Low security template as it had been prior to IE7 – not a good idea!)
With FDCC, all these decisions are removed from end users. The primary policy which enforces this is “Security zones: Use only machine settings”: User Policies and Preferences for security zones are ignored in favor of Machine Policies and Preferences, and the same settings apply to all users of the computer. The IE security zone settings that FDCC requires are implemented as Machine Policies. Since users are not allowed to change any system-wide configuration settings, this setting blocks users from adding or removing sites from the Trusted sites, Restricted sites and Local Intranet zones, from changing the security level of or individual security settings within any of the zones. Consequently, another effect of this setting is that most of the standard UI for viewing or changing IE security zone settings is disabled:
One drawback is that users (and admins) cannot use this dialog to see what the effective security settings are for a given zone. “IE Zone Compare” is a new tool that makes that information visible. It will be posted on this blog later in the “FDCC and Internet Explorer 7” series.
(Two related settings are “Do not allow users to add/delete sites” and “Do not allow users to change policies” . However, the “Use only machine settings” policy combined with users not having admin rights ends up having the same effect, but more completely and effectively.)
FIPS – “System cryptography: Use FIPS compliant algorithms…”
FDCC mandates that only FIPS compliant algorithms be used for all cryptographic operations. It’s actually more than FDCC – the law has required this of Federal agencies for many years. The main impact this policy has for Internet Explorer users is that HTTPS sites must use the TLS 1.0 protocol (sometimes known as SSL 3.1). SSL 3.0 and earlier are not FIPS compliant. Internet Explorer (and other Schannel clients) cannot negotiate a connection with sites that use SSL 3.0 or earlier. The symptom of this failure is the same that you’d get if the site were down completely: IE6 says “The page cannot be displayed” (“The page you are looking for is currently unavailable…”); IE7 displays “Internet Explorer cannot display the webpage” (“Most likely causes: You are not connected to the Internet…”).
Using TLS 1.0 requires the cooperation of the browser and the web server. On the browser side, make sure that the “Use TLS 1.0” option is checked on the Advanced tab of the Internet Options dialog. Note that on IE6 this is not checked by default (it is on by default in IE7). Unfortunately, there is no Group Policy to control this setting.
See the following Knowledge Base articles for more information about the effects of the FIPS setting:
· KB 811833: The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows
· KB 811834: PRB: Cannot visit SSL sites after you enable FIPS compliant cryptography
Prevent ignoring certificate errors
Draft versions of the FDCC GPOs required that “Prevent ignoring certificate errors” be enabled. Because of the huge amount of usability impact, this requirement was removed from FDCC Major Version 1.0, which was released on June 20, 2008. In other words, this setting is no longer required by FDCC. Get the latest SCAP content from fdcc.nist.gov to make sure that your compliance scans don’t flag this setting as missing or misconfigured.
When you browse an HTTPS site, Internet Explorer verifies the server’s digital certificate: it has to match the name of the site you’ve requested, it has to come from a trusted certificate authority, and its validity period must be current. If any of these verifications fail, the user is warned that something is amiss, as shown in this screenshot below. Ordinarily, the user is given the option to ignore the certificate error and to browse to the site anyway:
Continuing to the site is not recommended, because you don’t have assurance that the site is who they claim to be. Anybody can create a self-signed server authentication certificate that claims to be bankofamerica.com – but only the real Bank of America should be able to get a bankofamerica.com server authentication certificate from a trusted certificate authority.
When the “Prevent ignoring certificate errors” policy is enabled, the decision to continue to a potentially bad site is taken out of the user’s hands – the option to “Continue to this website” is removed, and the user cannot browse to the page:
This policy setting is security goodness, but FDCC removed the requirement to enable it because it turns out that within the government there are a lot of internal sites and network appliances that have self-signed certificates. There are also issues with certificate names: if the server name in the certificate says “sharepoint.internal.agency.gov”, then you can’t browse to https://sharepoint – you have to use the fully-qualified domain name. Similarly, if the name in the certificate is just “sharepoint”, then there is no way to get there if you have to use the FQDN to resolve it.
Note that “Prevent ignoring certificate errors” is a completely separate issue from the FIPS issue.
Java, and Java Permissions
The “Java Permissions / Disable Java” setting that had been applied to all security zones in draft versions of the FDCC caused some unintended problems, as we described here. FDCC Major Version 1.0 changes the setting to “High safety” for the Intranet and Trusted Sites zones, so non-Microsoft Java should be able to run in those zones.
Sun Java can have problems running in Internet Explorer Protected Mode on Windows Vista. Recommendations about Protected Mode will be the topic of the next post in this series.
User goodies
FDCC disables auto-complete in forms and will not save passwords typed into forms or authentication dialogs.
FDCC disables 3rd party browser extensions. This disables toolbars like MSN’s and Google’s, and integration with Acrobat Reader and instant messaging programs. Hopefully it will also block a lot of the malware and spyware that is implemented as browser helper objects, toolbars, etc.
Comments
- Anonymous
January 01, 2003
This is the [long-delayed] third installment in a series discussing various issues regarding the intersection