Cover V06, I06
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Listing 1
Listing 2
Listing 3
Sidebar 1
Sidebar 2
Sidebar 3
Sidebar 4


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:

  • login ID

  • encrypted password

  • numeric user id

  • numeric group id

  • user identification (gecos)

  • initial working directory

  • shell program

    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:

  • password lengths up to 40 characters

  • system or user generated passwords

  • minimum length passwords and prohibition of null passwords

  • password triviality tests verifying it is not a loginid or group name, key sequence, palindrome or a word recognized by the spell(1) program

  • recording of last successful and unsuccessful password change

  • account locking after a maximum number of unsuccessful logon attempts

  • time delays between unsuccessful logon attempts

  • recording and display of both the last successful and unsuccessful logon

  • administrative account locking

  • locking of inactive accounts

  • time of day or day of week logon restrictions

  • logins restricted to particular terminals or hosts

    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:

  • create a new trusted computing file structure under /tcb

  • create a new protected password database under /tcb/files/auth

  • create default security options for users, passwords, and terminals

  • move encrypted passwords from /etc/passwd to the new Protected Password Database

  • replace the encrypted password field in /etc/passwd with an asterisk (*)

  • create an unique audit id and set the audit flag for all users

    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
    /tcb/files/ttys                   Terminal Control

    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
    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.


    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 Author

    Ben 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