focuses on the control of permissions and passwords within the UNIX ... The
Internet Worm highlighted two of UNIX's most serious weaknesses: the security.
Previous screen
84-01-13 Controlling UNIX Permissions and Passwords Marie A. Wright Payoff UNIX has a reputation of being a nonsecure operating system. In practice, this reputation is valid, although much of the blame for UNIX's security flaws should more rightfully be attributed to user and system administrator practices than theoretical design. This article focuses on the control of permissions and passwords within the UNIX operating system. It also offers suggestions for establishing and maintaining adequate system security.
Introduction UNIX is a trademark in operating systems. When it was originally developed at AT&T's Bell Laboratories in the early 1970s, UNIX had no security features. At the time, security was perceived to be an unnecessary nuisance; planning for it could only impede the running of programs and prevent UNIX from being what it was designed to be: a relatively inexpensive, easily modified, highly portable operating system. As UNIX's popularity grew, security features were added in piecemeal fashion. Licensing restrictions forced most computer manufacturers to offer their own versions: Sun Microsystems Computer (SunOS), Hewlett-Packard (HP-UX), Digital Equipment Corp.(ULTRIX), IBM Corp. (AIX), Apple Computer, Inc. (A/UX), and Microsoft Corp. (Xenix). Each manufacturer made its own modifications to the operating system, changing the behaviors of specific system programs and affecting the level of security provided. The consequences of treating security as an afterthought were demonstrated in November 1988. Robert Morris's Internet Worm exploited flaws in certain standard utility programs in the University of California at Berkeley's BSD (Berkeley Software Distribution)versions of UNIX, which infected thousands of computers on the Internet. The scope of the attack was unforeseen, and its impact raised the overall level of security consciousness. The Defense Advanced Research Projects Agency established the Computer Emergency Response Team (CERT) at Carnegie Mellon University to provide support during Internet security emergencies. In addition, it was understood that network security depended on alert and aware users and system administrators. The Internet Worm highlighted two of UNIX's most serious weaknesses: the security of the entire operating system can be compromised from a single flaw in a UNIX system program, and system resources can be dominated, causing system performance to be slowed down or stopped (a situation known as denial of service). Despite these faults, UNIX can provide an acceptably secure operating environment. The key is the use of appropriate and fundamental administrative procedures.
Permissions Security Issues Permissions are the principal means for protecting data stored in files. Each file has three domains of security: ·
The user is the owner of a file.
·
The group that owns a file.
·
All other users on the system. Each domain has three types of permission:
·
Read allows a file to be accessed.
·
Write allows a file to be added, overwritten, or modified.
·
Execute allows a program to be run.
Previous screen
Because permissions are granted to each domain of security within the UNIX operating system, they determine who can access or modify the stored data. UNIX also stores the contents of directories in files. Each directory has the same three domains of security (i.e., user, group, and other), but the meanings of the three types of permission are interpreted differently: ·
Read allows files in a directory to be identified.
·
Write allows files in a directory to be added or removed.
·
Execute allows a file's attributes to be identified.
By default, UNIX typically creates new files withread and write permissions granted to the user, group, and other domains. Executable files (i.e., programs) and directories usually are created withread, write, andexecute permissions granted to theuser, group, andother domains. The default permissions for new files and directories can be altered by invoking the user file creation mode mask (umask) command. After a file or directory has been created, permissions can be granted or altered by using the change mode ( chmod) command. Many security problems are a result of carelessly set permissions. For example, when write permission is granted to the other domain in a directory, any user can create, rename, or remove any file in that directory. The system administrator should know how a file or directory is used to determine the permissions necessary for its security. It is particularly important that users understand the meaning and importance of file permissions, because they could inadvertently allow universalread and write access to all of their files. Because permissions are the cornerstone of UNIX security, the system administrator should review the status of all file and directory permissions on a regular basis. Files and directories that are not meant to be publicly accessible should be set with a restrictive set of permissions. For example, rather than accept the default permissions for new files, it is more secure to grant only theuser domain read andwrite permissions; no permissions should be granted to the group orother domains.
Special Permissions Two special permissions apply only to programs, and both of these can present security problems. Set user identity(SUID) allows a program to be run under another user's identity. The identity assumed and the permissions granted are the same as those of the user who created the program. Set group identity (SGID) allows a program to be run under the identity of another group. SGID andSUID permissions function similarly. They differ only with respect to their security domains. Both SUID and SGIDpermissions are intended to allow users controlled access to specific system resources. The idea of allowing a user to run a program under a different identity might appear to be a security risk; however, this is not the case if the program is correctly installed and its permissions are properly set. Moreover, this capability has several useful applications. For example, the password(passwd) program is an SUIDprogram
Previous screen
that enables users to change their passwords but prevents them from changing the passwords of other users. SUID and SGID programs are supposed to perform only the specific, compiled functions for which they were designed. Unfortunately, it is particularly difficult to predict the interaction between an SUIDprogram and other system programs. As a result, SUID programs that execute with root privileges should be avoided. Some forms of UNIX allow the shell scripts (special programs that process user commands) to use SUID orSGID permissions. UNIX shell scripts set with these permissions enable a user to gain super user status; they are not secure and should not be used. SGID orSUID permissions should be used only when identified as necessary in the system documentation or when super user privileges are required. SUID and SGID programs can be located by using the list (ls) command or the find command. The system administrator should routinely search the system for all programs with these special permissions. The creation of new SUID orSGID programs should be investigated, because intruders (as well as authorized users) frequently use these programs as a trapdoor to regain super user privileges.
Passwords and Protection UNIX's evolution toward security is evident in the changes that have been introduced to store user passwords safely. Initially, passwords were stored in plaintext form in a file that was only meant to be accessible by certain operating system utility programs and by those few users with the appropriate privileges. When password security was breached, human error, carelessness, and the occasional, unpredictable interaction between system programs were the attributable causes. Most versions of UNIX use an encrypted password system to store the passwords of authorized system users. Before it is stored, each password is encrypted using a one-way function called crypt. This function is based on the Data Encryption Standard (DES) algorithm. It uses each password as the private key in the cryptographic transformation process. The time of day is also incorporated in the resulting ciphertext. When a user logs in, the password that is entered is encrypted and compared with the encrypted password stored in the system. If the two passwords match, access is allowed. In less secure versions of the UNIX operating system, passwords are stored in the password (/etc/passwd) file. This file contains the account names, encrypted passwords, user and group identities, and allowable permissions for all authorized users. The/etc/passwd file should be generally readable to make the user log-on names publicly accessible; however, advances in computer processing power have enabled brute force attacks to successfully decrypt the stored passwords. More trusted versions of UNIX hide the encrypted passwords in a shadow password file. If this adjunct file is set with the proper permissions, it is not readable by most system users. Strong password security is a critical defense against the unauthorized use of system resources. However, password misuse has become so commonplace that it is seen as the rule rather than the exception. Because the strength of the crypt algorithm depends on the difficulty of determining a user's password, awareness of effective password management is essential. To maintain individual accountability, the system administrator should assign each user a unique account. Group accounts pose a risk; if a security violation occurs using such an account, the individuals responsible cannot be identified. Default accounts, guest accounts for visitors, or accounts established for demonstration purposes create system vulnerabilities, because they usually have obvious passwords that are easily guessed. If default accounts must be used, their passwords should be changed. Dormant accounts (i.e., the accounts of those users who have quit, retired, been transferred, or been
Previous screen
terminated) as well as the accounts of users who are on extended vacations should be disabled. The responsibility for day-to-day protection of passwords falls more to users than to system administrators. As a result, users must be taught and routinely reminded of the meaning and necessity of effective password security.
Password Selection Each user account should have a password that is easy for the user to remember but difficult for others to guess. A pronounceable nonsense word, at least eight characters long that uses a combination of upper- and lowercase letters, special characters, and digits is a good choice. Names, birthdays, and numeric strings (e.g., a user's social security number or telephone number) make weak passwords and should be avoided. Passwords should not be written down. They should never be shared, transmitted through electronic mail, or stored online. If a password is believed to have been compromised, it should be changed immediately. All passwords should be changed on a regular basis (even if they are not thought to be compromised). What constitutes a regular basis depends on the organization, the system, and the data stored in the system. However, a reasonable time frame might call for passwords to be changed once every three or four months. In some UNIX systems, the system administrator can age passwords. The life of a password is determined by the time established by the system administrator. When the specified time is reached, the user's current password expires, and the user must then enter a new password to log on to the system. This mechanism encourages users to remain security-conscious by periodically forcing them to change their passwords. Rather than rely on the users' judgment in choosing passwords, some versions of UNIX automatically produce system-generated passwords. In some cases, these passwords are pronounceable; in virtually all cases, they are stronger than those that are user-generated. However, users sometimes find these passwords difficult to remember and may write them down, thereby making them unsecure. Fortunately, system security can be upheld even if passwords are written down. The salient requirement is user education. A written password can be hidden in noise—random letters, numbers, and symbols should surround the password and cover the paper. The user's account name should not be written down, and the paper should not be openly displayed in the vicinity of the computer.
User Log-On Controls UNIX offers a number of user log-on controls. These features are stored in log files within the /usr/admdirectory. UNIX log files can be used to identify suspicious activities: unusual log-on times, log-ons from unexpected or unfamiliar network sites, unsuccessful log-on attempts, or extraordinary changes in system programs or user files. Recorded in the /usr/adm/lastlog file are the last log-on dates and times of all authorized users. This information allows alert end users to participate in the detection of unauthorized system access. Whenever a user logs on to the system, UNIX displays the user's last logon date and time. If the user believes that the information displayed by the system is incorrect, the system administrator should be notified, and the user's password should be changed. All user log-ons and log-offs are recorded in either the/etc/wtmp file or the/usr/adm/wtmp file. (Different versions of UNIX use different file names). From this log file, the system administrator can track a user's total time on the system, determine the exact times that a user logged on and logged off, and detect user log-ons from unusual sites.
Previous screen
The /usr/adm/acct file records all of the commands executed by all of the system users. The system administrator can use this file to monitor an intruder's activities as well as the activities of authorized system users. Because they are the mainstay of the operating system's auditing capabilities, UNIX log files are potential targets for modification by knowledgeable intruders attempting to hide their activities. To prevent such alteration, these files should be set with restricted permissions (i.e., the group andother domains should not be grantedread or write permissions). Detecting unauthorized changes requires that the system administrator review the log files daily.
Conclusion For UNIX to provide an acceptable secure operating environment, the system administrator and all users must be aware, alert, and security-conscious at all times. This article offers suggestions for establishing and maintaining UNIX system security. Some of the more critical recommendations are summarized as follows: ·
Permissions should be assigned according to theprinciple of least privilege; files and directories should be set with the most restricted set of permissions necessary to perform authorized tasks.
·
The creation of SUID root programs should be avoided.
·
The status of all file and directory permissions should be reviewed on a regular basis.
·
User accounts should be established and monitored with individual accountability in mind.
·
Shadow password files should be used to hide the encrypted passwords.
·
Passwords should be chosen carefully, changed frequently, and kept secret at all times.
·
Users must be educated and reminded of the meaning and importance of file permissions and password security.
·
Log files can be used to identify suspicious activities, and they should be reviewed daily.
UNIX security is an ongoing challenge, and assistance can be found in the form of books and online resources. Details of specific UNIX commands and options are provided in the manufacturer's system documentation. To supplement these details, two books are particularly valuable references: ·
Garfinkel, S. and Spafford, G. Practical UNIX Security. Sebastopol CA: O'Reilly & Associates, Inc., 1994. ISBN: 0-937175-72-2.
·
Arnold, N.D. UNIX Security, A Practical Tutorial. New York: McGraw-Hill Inc., 1993. ISBN: 0-07-002560-6.
During Internet security emergencies, the Computer Emergency Response Team offers immediate and useful assistance. The address is: Computer Emergency Response Team (CERT)
Previous screen
Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213 E-mail:
[email protected] Telephone: (412) 268-7090 (24-hour hotline) In addition to providing emergency help, CERT alerts users to potential security problems, outlines security precautions, and identifies software patches that can be used to protect UNIX systems.
Author Biographies Marie A. Wright Marie A. Wright, BS, PhD, is an associate professor of management information systems at Western Connecticut State University. She is a member of the Association for Computing Machinery, the Boston Computer Society, the ISSA, the IEEE, and the NCSA.
