84-01-19 DATA SECURITY MANAGEMENT INTRODUCTION TO UNIX SECURITY FOR SECURITY PRACTITIONERS Jeffery J. Lowder INSIDE Operating System Security Services; Identification and Authentication; Access Control; Availability and Integrity; Audit; Security Facilities for Users; Vulnerabilities in Traditional UNIX; TCP Wrappers; Login or Warning Banners In an age of increasingly sophisticated security tools (e.g., firewalls, vir- tual private networks, intrusion detection systems, etc.), many people do not consider operating system security a very sexy topic. Indeed, given that the UNIX operating system was originally developed in 1969 and that multiple full-length books have been written on protecting UNIX machines, one might be tempted to dismiss the entire topic as “old hat.” Nevertheless, operating system security is a crucial component of an overall security program. In the words of Anup Ghosh, the operating sys- tem is “the foundation for any software that runs on a machine,” and this is just as true in the era of E-commerce as it was in the past. Thus, secu- rity practitioners who are even indirectly responsible for the protection of UNIX machines need to have at least a basic understanding of UNIX security. This article attempts to address that need by providing an over- view of security services common to all flavors of UNIX; security mech- anisms available in trusted UNIX are beyond the scope of this article (but see Exhibit 1). OPERATING SYSTEM SECURITY SERVICES PAYOFF IDEA Summers1 (1997) lists the following Operating system security is a crucial component security services that operating sys- of an overall security program. Thus, security tems in general can provide: practitioners who are even indirectly responsible for the protection of UNIX machines need to have at least a basic understanding of UNIX security. 1. Identification and authentica- This article addresses that need by providing an tion: A secure operating system overview of security services common to all fla- vors of UNIX. Auerbach Publications © 2000 CRC Press LLC EXHIBIT 1 — Versions of Trusted or Secure UNIX A1 (Verified Design) No operating systems have been evaluated in class A1 B3 (Security Domains) Wang Government Services, Inc., XTS-300 STOP 4.4.2 B2 (Structured Protection) Trusted Information Systems, Inc. Trusted XENIX 4.0 B1 (Labeled Security Protection) Digital Equipment Corporation ULTRIX MLS+ Version 2.1 on VAX Station 3100 Hewlett Packard Corporation HP-UX BLS Release 9.09+ Silicon Graphics Inc. Trusted IRIX/B Release 4.0.5EPL C2 (Controlled Access Protection) No UNIX operating systems have been evaluated in class C2 C1 (Discretionary Access Protection) Products are no longer evaluated at this class D1 (Minimal Protection) No operating systems have been evaluated in class D1 Note: Various versions of UNIX have been evaluated by the U.S. Government’s National Security Agency (NSA) according to the Trusted Computer System Evaluation Criteria. (By way of comparison, Microsoft Corporation’s Windows NT Worksta- tion and Windows NT Server, version 4.0, have both been evaluated at class C2.) The above chart is taken from the NSA’s Evaluated Product List. must be able to distinguish between different users (identification); it also needs some assurance that users are who they say they are (au- thentication). Identification and authentication are crucial to the oth- er operating system security services. There are typically three ways to authenticate users: something the user knows (e.g., a password), something the user has (e.g., a smart card), or something the user is (e.g., a retinal pattern). Passwords are by far the most common au- thentication method; this method is also extremely vulnerable to compromise. Passwords can be null, easily guessed, cracked, written down and then discovered, or “sniffed.” 2. Access control: An operating system is responsible for providing log- ical access control through the use of subjects, objects, access rights, and access validation. A subject includes a userID, password, group memberships, privileges, etc. for each user. Object security informa- tion includes the owner, group, access restrictions, etc. Basic access rights include read, write, and execute. Finally, an operating system evaluates an access request (consisting of a subject, an object, and the requested access) according to access validation rules. 3. Availability and integrity: Does the system start up in a secure fash- ion? Does the system behave according to expectations during an at- tack? Is the data on the system internally consistent? Does the data correspond with the real-world entities that it represents? Auerbach Publications © 2000 CRC Press LLC 4. Audit: An audit trail contains a chronological record of events. Audit trails can be useful as a deterrent; they are even more useful in inves- tigating incidents (e.g., Who did it? How?). Audit trails have even been used as legal evidence in criminal trials. However, for an audit trail to be useful in any of these contexts, the operating system must record all security-relevant events, protect the confidentiality and in- tegrity of the audit trail, and ensure that the data is available in a timely manner. 5. Security facilities for users: Non-privileged users need some method for granting rights to their files and changing their passwords. Privi- leged users need additional facilities, including the ability to lock ac- counts, gain access to other users’ files, configure auditing options, change ownership of files, change users’ memberships in groups, etc. The remainder of this article explores how these services are imple- mented in the UNIX family of operating systems. IDENTIFICATION AND AUTHENTICATION UNIX identifies users according to usernames and authenticates them with passwords. In many implementations of UNIX, both usernames and passwords are limited to eight characters. As a security measure, UNIX does not store passwords in plaintext. Instead, it stores the password as ciphertext, using a modified Digital Encryption Standard (DES) algorithm (crypt) for encryption. The encrypted password, along with other perti- nent account information (see Exhibit 2), is stored in the /etc/passwd file according to the following format: username:encrypted password:UserID:GroupID:user’s full name:home directory:login shell Unfortunately, the /etc/passwd file is world-readable, which can place standard, “out-of-the-box” configurations of UNIX at risk for a brute-force password-guessing attack by anyone with system access. Given enough computing resources and readily available tools like Alec Muffet’s crack EXHIBIT 2 — Sample /etc/passwd Entries keith::1001:15:Keith Smith:/usr/keith:/bin/csh greg:Qf@14pL1aqzqB:Greg Jones:/usr/greg/:/bin/csh cathy:*:1003:15:Cathy Jones:/usr/cathy:/bin/csh Note: In this example, user keith has no password, user greg has an encrypted password, and user cathy has a shadowed password. Auerbach Publications © 2000 CRC Press LLC utility, an attacker can eventually guess every password on the system. In light of this vulnerability, all current implementations of UNIX now pro- vide support for so-called “shadow” passwords. The basic idea is to store the encrypted passwords in a separate file (/etc/shadow to be exact) that is only readable by the privileged “root” account. Also, although vanilla UNIX does not provide support for proactive password checking, add-on tools are available. Finally, password aging is not part of standard UNIX but is supported by many proprietary implementations. UserIDs (UIDs) are typically 16-bit integers, meaning that they can have any value between 0 and 65,535. The operating system uses UIDs, not usernames, to track users. Thus, it is entirely possible in UNIX for two or more usernames to share the same UID. In general, it is a bad idea to give two usernames the same UID. Also, certain UIDs are reserved. (For example, any username with an UID of zero is considered root by the operating system.) Finally, UNIX requires that certain programs like /bin/passwd (used by users to change their passwords) and /bin/login (executed when a user initiates a login sequence) run as root; however, users should not be able to arbitrarily gain root permissions on the sys- tem. UNIX solves this problem by allowing certain programs to run un- der the permissions of another UID. Such programs are called Set UserID (SUID) programs. Of course, such programs can also be risky: if attackers are able to interrupt an SUID program, they may be able to gain root ac- cess and ensure that they are able to regain such access in the future. Group IDs (GIDs) are also typically 16-bit integers. The GID listed in a user’s entry in /etc/passwd is that user’s primary GID; however, in some versions of UNIX, a user can belong to more than one group. A complete listing of all groups, including name, GID, and members (users), can be found in the file /etc/group. Once a user successfully logs in, UNIX executes the global file /etc/profile along with the .profile file in the user’s home directory using the user’s shell specified in /etc/passwd. If the permissions on these files are not restricted properly, an attacker could modify these files and cause unauthorized commands to be executed each time the user logs in. UNIX also updates the file /usr/adm/lastlog, which stores the date and time of the latest login for each account. This information can be obtained via the finger command and creates another vulnerability: systems with the finger command enabled may unwittingly provide attackers with useful information in planning an attack. ACCESS CONTROL Standard UNIX systems prevent the unauthorized use of system resourc- es (e.g., files, memory, devices, etc.) by promoting discretionary access control. Permissions are divided into three categories: owner, group, and other. However, privileged accounts can bypass this access control. UNIX Auerbach Publications © 2000 CRC Press LLC treats all system resources consistently by making no distinction between files, memory, and devices; all resources are treated as files for access control purposes.