Limiting Access to Data and Configuration Files

Should an attacker obtain remote access to the system through a non-administrative account, he will often look for ways to elevate his privileges to gain full control over the host and to access sensitive data or configuration files. By taking the time to set the appropriate access restrictions on such files, you can significantly impede the attacker's progress. In this section we take a brief look at defining file systemlevel permissions for UNIX and Windows, as well as limiting permissions to the Registry on Windows systems.

In order to implement file access restrictions, you need to make sure the host uses a file system that supports security permissions. Legacy file systems for DOS and Windows, such as FAT and FAT32, cannot restrict file access, granting all local users full control over any file on the host. Microsoft has since equipped Windows with a much more powerful file system, called NTFS, that allows administrators to control who can access a local file and what that user can do with it. At this point, NTFS and the associated management and recovery tools are sufficiently mature that situations where it would make sense to deploy a FAT-based file system, rather than NTFS, are very rare.

Like NTFS, UNIX-based file systems allow administrators to restrict file access based on the user's identity. Although UNIX platforms are typically more careful about grant-ing file permissions than Windows, attackers may still exploit vulnerabilities because of loose file permissions on default installations of UNIX operating systems.

File Permissions and Race Conditions

One type of vulnerability often associated with incorrect file permissions, in conjunction with coding errors, is a race condition. In a common incarnation of this attack, during a brief window of opportunity, files are temporarily assigned file permissions that allow anyone to access them. Attackers can then manipulate these files to elevate their access on the host. For example, a race condition in FreeBSD's rmuser script allowed a local user to extract all password hashes from the system while the administrator removes a user (http://www.securityfocus.com/advisories/3544). This attack was possible because rmuser created a temporary file that was world-readable.

Default installations of both Windows and UNIX operating systems usually result in settings that are overly permissive. Host-hardening checklists, which we reference at the end of this chapter, offer detailed guidelines for protecting specific files and directories after installing the OS. The general idea behind such steps is to provide users with only the minimum access required to perform their tasks.

Be sure to carefully test the system's configuration after tightening its file system permissions to verify that the necessary applications continue to function. For example, if you restrict default permissions in the %SystemRoot% directory on Windows, this might create a problem when a user attempts to print. The %SystemRoot%\system32\spool\ printers folder requires read and write access for users to be able to print successfully.

UNIX operating systems typically use files for storing OS and application-related configuration details. Limiting access to such data involves manipulating file systemlevel access restrictions. Although Windows also uses files for storing some configuration parameters, it increasingly relies on the Registry database for maintaining local system information. You can use the Regedit32 and Regedit utilities that come with Windows to set access control restrictions on Registry keys, just like you would set them on files. If your organization is using Active Directory, you can also distribute Registry permission settings through Group Policy.

Note

Applying file and Registry access restrictions can be a tedious task. You will be most effective at completing this step of the hardening process if you automate it, as we discuss in the "Automating Host-Hardening Steps" section later in this chapter.

The process of limiting access to powerful programs and sensitive files goes hand in hand with user and group management practices, which we cover in the following section.