Can You Trust HP-UX?
Ben N. Klein
UNIX was not designed to be a secure operating system. Its design was intended to allow users to work together on a time-shared system in a collaborative, relatively friendly environment. In today's world of Internet-connected systems and unfriendly hackers, vanilla UNIX makes it relatively easy for unauthorized users to access your system. In fact, there is little to prevent them from using your very own login ID and password to do so. To combat this, UNIX vendors have added extensions to their systems to make their UNIX variants more resistant to this direct misuse of legitimate login IDs and passwords. In the past, vendors used shadow password files for that purpose. Like other vendors, Hewlett Packard strives to improve the security of their UNIX systems. They have created a significantly improved, trusted computing environment with their latest version of UNIX. HP-UX 10 includes a C2-level, trusted system for controlled access protection, as spelled out in the Department of Defense Trusted Computer System Evaluation Critera (DOD 5200.28-STD. Section 2.2, December 1985). This article examines some of the historical design aspects of UNIX that relate to security and addresses documented and undocumented C2 security features of HP-UX 10. Why You Should Worry UNIX was originally designed for use in departmental environments in which all users were known and trusted. However, UNIX has grown far beyond its original use, and its insecurities are beginning to show now more than ever. One of the biggest of these insecurities is the requirement that its password file be readable by all users and processes on the system. The system password file must have global read permission because UNIX uses only the numeric uid with files and processes, not the login ID. Programs and utilities, such as ls and ps, must have access to the /etc/passwd file to translate and display the login IDs associated with the files and processes. The standard UNIX password file contains the following information for each user:
The primary danger of having all this information publicly accessible is that it can be easily copied and used to break encrypted passwords. Encrypted UNIX passwords can not be decrypted directly. Instead, they must be broken by guessing what the password is, encrypting the guess, and comparing it with the encrypted password in the password file. These initial password guesses are usually based on information in the password file itself, specifically the login ID and information in the user identification (gecos) field. Variations of passwords based on this data are tried next, followed by words commonly used as passwords, such as names, colors, months, days, key sequences, and technical jargon. Crack programs next try words from English and foreign dictionaries. If these fail, variants of the previous guesses are tried. These variants include preceding or appending numbers and special characters, substituting numbers for letters (such as the digit 0 for the letter o, and 1 for the letters i or l), and reversing characters. In the past, this was not much of a threat because of the cpu requirements that such a brute force approach required. However, cpu power is no longer a limitation. That power and programs such as Crack, with its dictionary of thousands of words and word manipulation algorithms, make guessing passwords easy. This is all made possible by the general accessibility of the encrypted passwords in the UNIX system's password file. Shadow Password Files It is accepted that the password file /etc/passwd file must be globally accessible. However, there is no requirement that the encrypted passwords have such universal access. Many UNIX vendors have made their systems more secure by moving their encrypted passwords to shadow password files allowing only root access. The HP-UX shadow password file in previous releases was /.secure/etc/passwd. It contained the login ID, encrypted password, a numeric audit id, and numeric audit flag. This solution put the encrypted password safely out of harm's way. However, the fact that it did little to answer the growing list of security issues has made this solution inadequate for today's demands. New and Improved Commercial Security HP-UX 10 includes the trusted, C2 commercial security option. When implemented, it replaces the simple shadow password file used in previous releases with a series of files that make up its trusted computing base file structure. This series of files, associated system calls, and commands enable many new and enhanced security features. These features include:
The trusted security option is easily implemented using SAM, HP-UX's System Administration Manager. Select the main menu selection, "Auditing and Security" and simply respond YES to the "Convert to Trusted System" prompt. Conversion to the new trusted system will perform the following:
The most visible sign that the system has been converted to a trusted system are the messages that are displayed when users logon.
Last successful login for user001: Wed Apr 1 21:05:40 GMT \ 1997 on ttyp1 Last unsuccessful login for user001: Fri Feb 28 17:28:54 \ GMT 1997 on console
Conversion back from a trusted system is an equally easy process. The "Audited Events," "Audited System Calls" and "Audited Users" selections in the "Auditing and Security window all have an unconvert option. Security Options SAM's "Auditing and Security" window has a "System Security Policies" selection that sets the trusted system's default options. These options apply to all users and terminals unless user or terminal specific options are set to override them. Figure 1 notes system-wide options that can be specified. Options also can be set for individual users, overriding the default system-wide security options. SAM provides access to the user options from its "Accounts for Users and Groups"/"Users" action bar. User security options are noted in Figure 2 and include some of the same as those listed under system-wide options. The additional user action, "Activate," is used to reactivate a user that has been disabled due to exceeding the allowed number of logon attempts, exceeding the number of days between logins, or having been deactivated. "Deactivate" places an administrative lock on a user account, and "Set Authorized Login Times" sets restrictions on when users may log in to the system. Many of these options can be set and displayed outside of SAM using the undocumented modprpw and getprpw commands noted later in this document. The Trusted Computing Databases The trusted computing system utilizes a Default, Protected Password, Device Assignment, and Terminal Control Databases. Collectively, they are used to implement and control the system's security policies. The Default Database defines system-wide values that apply to all login IDs, devices, or terminals unless they are specifically overridden. The use of modifiable defaults makes global changes easier should there be a need for them. The Protected Password Database is actually a hierarchy of files and directories. A Protected Password Database file for each login ID is placed in a directory under /tcb/files/auth corresponding to the first letter of the login ID. These are the files that contain an individual user's encrypted password and other information that controls the user's security options. The Device Assignment Database is a single file that contains entries for the login IDs that are permitted to use local and remote login terminals, printers, and devices used for import or export. The Terminal Control Database is a single file that contains entries that determine if login to that terminal is permitted. The following are the trusted computing system's databases that are located under /tcb/auth.
/tcb/files/auth/x directory for login IDs beginning with "x" /tcb/files/auth/x/logonid Protected Password Database for "logonid" /tcb/files/auth/system/default Default Database /tcb/files/auth//system/pw_id_map dynamically built index file /tcb/files/devassign Device Assignment Database /tcb/files/ttys Terminal Control Database
Database options begin with the characters "d_", "u_", "t_" and "v_", which correspond to options related to the Default, Protected Password, Terminal Control, and Device Assignment databases, respectively. The Default Database typically contains both its own options and those applied globally to the Protected Password and Terminal Control databases. Figures 3 and 4 4 show a sample Default Database and sample Protected Password Database. All trusted database files share the same ASCII format. Entries are made up of multiple fields, each separated by a colon (:). The backslash (\) character can be used to span physical records. Each entry has 0 or more capabilities defined. Numeric capabilities have the format: id#number, where the number is decimal or octal if preceded by 0. Boolean capabilities have the format: id, which denotes the presence of the capability, or id@, which represents the absence of the capability. String capabilities have the format id=string, where the string is 0 or more characters. The and : characters are escaped as\ and:, respectively. The end of each entry is terminated by chkent. All of the databases use a lock file consisting of the database filename with -t appended. The presence of the lock file normally means the database is currently being rewritten. However, lock files can remain after a system crash or other abnormal event and may need to be deleted manually. Listing the contents of a Protected Database can give a quick indication of the status of a user. For example, the most common reason a login ID becomes disabled is because the maximum number of consecutive unsuccessful logins is exceeded. This can quickly be determined by examining the u_numunsuclog field in the login ID's Protected Database. Unfortunately, it is more difficult to find and display an individual user's Protected Database file than to look at the single shadow password file used in past releases. There are as many Protected Database files as there are login IDs, and each is in a directory that corresponds to the first character of the login ID. The script, list_pdb (Listing 1) can be used to easily locate and display the contents of one or more of the Default or Protected Database files. Each Protected Database record can contain any number of fields making it difficult to directly use them. The following awk procedure can be used to reformat the Default or Protected Password Databases directly or from the piped output of list_tcb (Listing 1).
/usr/bin/awk 'BEGIN { FS="[\t:\]" }
{ for (i = 1; i <= NF; i++)
if ( $i != "" )
if ( i == 1 )
print $i
else
print " " $i
} '
The Undocumented Commands HP-UX 10 includes undocumented commands that can be used to display and modify the contents of the trusted system databases outside of SAM. The commands getprdef, modprdef, getprpw, and modprpw are used to display and modify the Default Database and user Protected Password Databases, respectively. Man pages for these commands have been developed and are included. There are similar commands getprdev, getprterm, modprdev, and modprterm that display and modify the Device Assignment and Terminal Databases. Note that these are undocumented commands and not supported for direct use by end users. The documentation for the commands has been gathered from multiple sources, inferred, or developed empirically. No warranty is provided for their accuracy, completeness, or use. Undocumented commands, by their very nature, can be changed or deleted at any time by system maintenance or subsequent software releases. Putting It to Use Three scripts have been included to show how information in Default and Protected Password Databases can be displayed and updated. Only root should be able to execute these scripts, because only root should be permitted access to the database files they reference. Do not modify the permissions of the files under /tcb. It is the restricted access to these files that help preserve the integrity of your system. The script, list_pdb Listing 1, displays the contents of the Default Database or Protected Password Database. However, many values, such as dates, are not in an easily readable form. A user's Protected Password Database also only includes the options specific to the user or overriding the defaults. It does not include any options for which the system defaults are being used. Thus, it is often difficult to see all of the options that apply for a user. The script, prpw (Listing 2), uses the getprdef and getprpw commands to display the Default Database and a user's Protected Password Database in a more complete form. The getprpw displays a "DFT" value when a user's Protected Password Database indicates that use of the system-wide default has been specified. A -1 value indicates that the option is undefined and the default will be used. The "DFT" and -1 values will be replaced by their corresponding defaults from the default database when the -m option is used with the prpw script. These merged values will be noted with an "=>". Figure 5 shows such a listing. The Perl script, reset_user (Listing 3), addresses two of the most common system administration problems, resetting disabled accounts and changing user passwords. The script first uses the modprpw -k command to reset the user's account. It also generates, encrypts, and assigns a random password of three alphabetic and four numeric characters using the modprpw -w command. Finally, it expires the temporary password, which requires the password to be changed after its first use. Maintenance and Support A word of caution. The trusted computing environment in HP-UX 10 has been updated considerably. As a result, there has been a significant amount of maintenance to correct problems as they were discovered in general use. Make certain that maintenance gets applied to ensure that preventable problems do not occur. There also are a number of products that do not work with the HP-UX 10 trusted computing environment. Programs that expect to work directly with the regular or shadow password files will have problems until they have been updated. However this has not been too much of a problem in the two years since HP-UX 10 first became available. Conclusion HP-UX 10's trusted computing environment provides a solution to some of the ever growing security needs of UNIX in a commercial environment. This secure computing option is easy to implement and not hard to manage given the additional commands documented in this article. Additionally, taking the steps necessary to reduce known security exposures by implementing C2 security increases your credibility and provides plausible deniability should something ever happen. But note that implementation of the trusted computing environment is not the solution by itself. Good security practices, such as good password and system administration practices, proper file and directory permissions, and keeping maintenance current, are still necessary.
About the AuthorBen Klein has worked as an Auditor, Application Programmer/Analyst, and Systems Programmer. He is currently an MIS Technical Specialist, managing a number of mission-critical Hewlett Packard, IBM, and Sun UNIX servers. Additionally, he holds multiple Certified Computing Professional designations from the Institute for the Certification of Computing Professionals. He can be reached at bklein@flash.net.
|