Freely available operating systems that perform varying levels of mission-critical functions — from providing development and testing environments to supporting full-scale enterprise resource planning systems — are found in all industries. Most of these operating systems are Unix-like in nature and include variants such as GNU/Hurd, FreeBSD, Open BSD, Darwin, and the most common of all, Linux.
Although audit strategies and methodologies exist for commercial Unix platforms — such as IBM's AIX, Hewlett Packard's HP-UX, and Sun Microsystems' Solaris — beginner IT auditors may be unaware of effective audit approaches for Linux systems due to Linux's recent use in the business world. A good place for internal auditors to begin audits of Linux-based operating systems is by understanding the system's file structure, the way file and directory permissions work, and how to access critical system files and locations.
Linux — A Bird's-Eye View
Linux was introduced in 1991 when Linus Torvalds, then a computer student in Finland, posted a message on Usenet regarding an operating system he was creating. Unlike most operating systems resembling Unix, Torvalds did not use any of the original Unix source code and chose to release his code under the GNU (Gnu's Not Unix) general public license. To this day, the GNU license allows the free distribution of Linux and its derivatives as long as copies are released under the same license and include the source code.
This public licensing also allows users to combine Linux's core operating system — essentially the kernel, its associated drivers, and loadable kernel modules — along with user applications and libraries to create distributions, software compilations commonly called distros that are published by companies and individuals. The more common distros in businesses today include Debian, Fedora, Gentoo, IBM's iSeries-Linux eServer, Koppix, Kubuntu, Novell's Suse, Red Hat, Slackware, Ubuntu, and Xandros. Although all Linux distros have the Linux kernel in common, the graphical user interface system, file structure, and desktop and server applications vary significantly, leading to subtle variations in audit approaches similar to those found in Unix.
Although Linux has a few unique risks, such as its lack of technical support for open-source software, most risks are variations on a common IT theme with a unique Linux slant. Like most technology audits, reviews of Linux systems concentrate on four main categories:
- Change control (e.g., patches and upgrades, data conversion, testing, and deployment).
- Management of the environment (e.g., policies, procedures, and executive oversight).
- Operations (e.g., performance, job scheduling and monitoring, training, and disaster recovery).
- Security (e.g., physical, environmental, and logical security, as well as monitoring and reporting).
Accordingly, most of the control objectives are the same, and even the control activities will be similar to those encountered in a mainframe, Microsoft Windows systems, or other IT environment. Areas such as user management, authentication mechanisms and tracking, privileged or super user access and activities, access to critical files, security logging and monitoring, configuration settings, patch management, and backup and recovery activities are just as important and should be addressed in a similar manner. However, due to the granularity and flexibility of system configuration, a deep knowledge of the architecture and understanding of the intended purpose is beneficial and perhaps required when designing, deploying, and auditing Linux systems.
Files — The Essential Nature of Linux
Linux is based on the concept that everything is a file. Running system processes and printers are files, configuration settings are stored in text files, and even directories are special files containing other files. Because the file is such a key element of Linux, file system security is a main control issue auditors need to consider. Although program and data files on all systems are always important during audit reviews, in Linux they should be the audit's focal point.
Different structures have been created to solve different file problems and needs, resulting in a number of file systems. For example, some file systems have robust redundancy and recovery capabilities, such as the Journaling File System (JFS); others are extremely fast, like Hans Reiser's File System (reiserfs); and others are highly scalable and can be distributed across entire networks, such as the Network File System (NFS). Most frequently, file systems follow the Filesystem Hierarchy Standard (FHS), the Linux File System Standard (FSSTND), or the Unified File System. The most common Linux file systems are ext2 and ext3. The specific file system structure in use will define the location of key operating system and service configuration files, as well as the directory structure and storage of application data and log information. Therefore, auditors need to make sure the file system type is appropriate for the nature of the function performed.
All file systems and structures in Linux start at the root of the system, indicated by a forward slash, /, analogous to C:\ in Microsoft Windows. However, the root is not limited to a single hard disk. Partitions, other hard drives, and remote file systems are mounted under directories, which when mounted can be designated as read-only or read-write. This provides immense flexibility in defining the system's layout, span, and access rights. A typical Linux file system might look similar to Figure 1.
Figure 1: Typical Linux file system
Audit Tip: All Unix-like systems, including Linux, have a built-in help system known as man pages that details different commands, files, and other system-related information. The man pages can be accessed by typing man <="" em="">>, as inman fs for information concerning file systems, or man cd for information on the change directory command. Use man manfor help on getting started.
Files and Directory Permissions
Within the Linux file system, files have permissions assigned to them that allow specific activities to be performed on the file. The most common of these permissions are read, write, and execute, denoted as r, w, and x, respectively, which are used when reviewing file listings. File permissions are sometimes given as octal values, a base 8 notation resulting from the binary nature of computers using the values 0 – 7. In this format 4, 2, and 1 correspond to read, write, and execute. The octal value of a file is obtained by adding the assigned permissions. Therefore, a file with read and execute, but not write permissions would have a value of 5 (read + execute = 4 + 1 = 5). A file with all permissions assigned, rwx, would have an octal value of 7.
All files have three types of users: the owner, an affiliated group, and everyone else, known as the World. As a result, each file has three different sets of permissions. The owner might be able to read, write, and execute a file; the group associated with the file might be able to read and execute, but not write the file; and the World might only be able to read the file, resulting in a file listing of rwxr-xr-- or an octal value of 754. The owner is always the first three spaces of the permissions, or the first digit of an octal value; the group is always the second three spaces of the permissions, or second digit of an octal value; and the World is always the final three spaces of the permissions, or the third digit of an octal value. To obtain a detailed file list, auditors can use the ls command followed by –al. This shows all files in a detailed format, as demonstrated in Figure 2.
Figure 2: Sample ls -al output
Additional characters may be present when listing file permissions. Of interest to auditors are the letters d and l. A dindicates the file is a directory and contains other files, the number of which is indicated by the number right after the permissions; an l indicates the file is a symbolic link to another file, indicated by the arrow following the file name and denoting the true linked file. For directories, the values of r, w, and x have slightly different meanings and indicate the ability to search the directory contents (i.e., r), alter the directory contents (i.e., w), and access (e.g., cd) the directory (i.e., x).
This information is crucial to performing an audit of Linux systems and is valuable when identifying World-readable and World-writable files — files that are accessible by all system users. Malicious users often search for files with these loose permissions, allowing them to access sensitive information or to elevate their access privileges. For example, a root owned, World-writable file with the setuid flag set can be exploited to gain root shell access. The worst of these offenders are sometimes called triple 7 or 777 files, which allow the owner, associated group, and everyone in the World to read, write, and execute the files. The exception to 777 files is symbolic links, which do not present a risk to the referenced file.
Auditors can use the find command to search for World-accessible files. For example, typing find / -type f –perm -7 –print 2> /dev/null allows auditors to identify 777 files anywhere on the system, while find /etc –type f –perm -2 –print 2> /dev/nullcan be used to find World-writable files in the /etc directory. Use man find for additional details.
All files are assigned a set of default permissions when first created. This default usually is configured in the /etc/profile file as the umask value. To obtain the umask value, auditors simply subtract the desired octal setting from 777. Therefore, if a file has an octal value of 755, the unmask value is 022: 777 - 755 = 022.
The umask value can be found in several locations on a Linux system and can exist multiple times. However, only one unmask value defines the default permissions. Therefore, auditors need to make sure they identify all locations where the umask is configured. A common security recommendation is to have an umask value of 022, resulting in default permissions of 755 (rwxrw-rw-). A more conservative recommendation is to have an umask value of 077, resulting in default permissions of 700 (rwx------).
Critical System Files and Locations
As mentioned previously, all configuration settings for Linux hosts are located in text files scattered throughout the file system. However, most distros have the majority of these files and directories located in the same area. A good starting point for auditors is to pay close attention to the following directories and the files they contain:
/bin, /boot, /etc, /root, /sbin, /tmp, /usr/bin, /usr/etc, /usr/sbin, /var/log, /var/run, /var/spool, /var/tmp
When familiarizing themselves with these directories, auditors should understand what files are stored in these directories, what parts of the system they control, and who has access to read and modify them.
Two of the most prominent Linux files in audit reports include /etc/passwd and /etc/group files. These two files identify all users and groups on the system and form the key to determining user management and access rights. The /etc/passwd file contains colon-separated fields that identify the assigned username, an encrypted hash of the user's password, the user identification (UID) value, primary group identification (GID) value, user information, user's home directory, and the shell or command interface assigned to the user in the following way: name:passwd:UID:GID:user_info:home_dir:shell (refer to Figure 3 for an example). If there is a character such as x, !, or * in the password field, it indicates the password is stored in a restricted file, known as /etc/shadow. A disabled user account is indicated by a !, *, or x in the password field of the/etc/shadow file. Auditors can use the more command to view files one page at a time.
Figure 3: Sample /etc/passwd file
The /etc/group file (see Figure 4 for an example) follows a similar format and uses colon-separated fields to identify the group name, the group password, the GID, and a list of additional users who are group members in the following manner:group_name:passwd:GID:additional_users. The cat command also allows viewing of file contents.
Figure 4: Sample /etc/group file
In Linux, a user can be an end user, a program, or system process that uses or owns system resources. A key user is the root user — a super-user, analogous to a domain administrator in Microsoft Windows, that has control of all system resources and activities. Root is the ultimate authority when it comes to the operation and control of a Linux host and the target account for all malicious individuals. The root user has a UID of 0 and should be the only user with this identifier. The reason for unique UID and GID values — for all users — is that the system does not track users or groups by their names, but rather by their identification number. Therefore, if two users share the same UID, the system will not be able to distinguish between the two when monitoring and logging their activities. Some administrators disable the root user and assign the UID of 0 to another user as a means to conceal the true authoritative account. Other users who require administrative access should be placed in a group with administrative rights. This group is known as the root group and has a GID of 0.
To find all members of the root or any other group, auditors must review the users listed in the /etc/group file to determine secondary group associations and the primary group listings found in the /etc/passwd file. Auditors can recommend that users needing administrative access, including system administrators, be given a normal account for daily activities and have their account included as a member of the wheel group, if available. The wheel group requires users to use the switch user (su) command any time they need to perform an administrative task and records such use in the su log.
Another key system file is the one that controls authentication requirements, such as password length, history, and complexity. This file is frequently the /etc/login.defs or /etc/default/passwd file, although some Linux systems use pluggable authentication modules for authentication mechanisms, in which case configuration settings are found in either /etc/pam.conf or in files within the /etc/pam.d directory. Replacement password utilities, such as npasswd, can be installed to provide more control over password requirements, check password strength against a given policy, or compare passwords against a list of unauthorized words.
Other files of importance to auditors include hidden files associated with users that configure settings unique to an individual account. These files — known as dot files, because they are preceded by a dot in their name (e.g., .profile, .login, and .bash) — may allow deviations from default settings established in system files. Although dot files are typically stored in a user's home directory, the root should own the files. Dot files also should not be accessible, or at least writable, to the user.
Many organizations and IT departments are using Linux-based operating systems to perform day-to-day business processes. As a result, it is essential that IT auditors understand the underlying functions of Linux systems and the most effective way to conduct audits. As the underlying structure for Linux, files provide an excellent point of departure for auditors who wish to learn more about Linux. Once auditors understand how file structures work and the way file and directory permissions are allocated, they can begin to look into the different critical system files and locations that affect business operations and security.
For additional information about Linux's file system structure, read Moshe Bar's Linux File Systems (2001), published by McGraw-Hill (ISBN 0-07-212955-7). In addition, to learn more about Linux, visit The Linux Documentation Project at www.tldp.org. This site provides a good starting point for auditors looking for Linux-related material.