Managing Standard Passwords and System Access

The password is the most important individual user identification symbol. With it, the system authenticates a user to allow access to the system. Since they are vulnerable to compromise when used, stored, or known, passwords must be kept secret at all times.

System Administrator’s Responsibilities

The system administrator and every user on the system must share responsibility for password security. The system administrator performs the following security tasks:

Ensure that all users have passwords.
Maintain proper permissions on all system files, including the standard password and group files, /etc/passwd and /etc/group.
Delete and/or nullify user IDs and passwords of users no longer eligible to access the system.

User’s Responsibility

Every user must observe the following rules:

Remember the password and keep it secret at all times.
Change the initial password immediately; change the password periodically.
Report any changes in status and any suspected security violations.
Make sure no one is watching when entering the password.
Choose a different password for each machine on which there is an account.

Criteria of a Good Password

Observe the following guidelines when choosing a password:

A password must have at least six characters and can have up to 80. Special characters can include control characters and symbols such as asterisks and slashes. In standard mode, only the first eight characters are used.
Do not choose a word found in a dictionary in any language, even if you spell it backwards. Software programs exist that can find and match it.
Do not choose a password easily associated with you, such as a family or pet name, or a hobby.
Do not use simple keyboard sequences, such as asdfghjkl, or repetitions of your login (e.g., if your login is ann; a bad password is annann).
Misspelled words or combined syllables from two unrelated words make suitable passwords. Another popular method is to use the first characters of a favorite title or phrase for a password.
Consider using a password generator that combines syllables to make pronounceable gibberish.

Management must forbid sharing of passwords. It is a security violation for users to share passwords.

Password File

A standard system maintains one password file: /etc/passwd.

If NIS+ is configured, this process is more complex; see “Network Information Service Plus (NIS+)”.

All passwords are encrypted immediately after entry, and stored in the password file, /etc/passwd. Only the encrypted password is used in comparisons.

Do not permit any empty/null password fields in the password file. This leaves a potential for security breach, because any user can set the password for that account before a password is set for the first time.

Do not edit the password file directly. Use SAM, useradd, userdel, or usermod to modify password file entries.

The /etc/passwd File

The /etc/passwd file is used to authenticate a user at login time for standard HP-UX. The file contains an entry for every account on the HP-UX system. Each entry consists of seven fields, separated by colons; see passwd(4). A typical /etc/passwd entry looks like this:

robin:Z.yxGaSvxAXGg:102:99:Robin Hood,Rm 3,x9876,408-555-1234:/home/robin:/usr/bin/sh

The fields contain the following information (listed in order), separated by colons:

User (login) name, consisting of up to 8 characters. (In the example, robin)
Encrypted password field. (Z.yxGaSvxAXGg)
User ID (uid), an integer ranging from 0 to MAXINT-1 (equal to 2,147,483,646 or 2³¹ -2). (102)
Group ID (gid), from /etc/group, an integer ranging from 0 to MAXINT-1. (99)
Comment field, used for identifying information such as the user’s full name, location, and phone numbers. For historic reasons, this is also called the gecos field. (Robin Hood,Rm 3,x9876,408-555-1234)
Home directory, the user’s initial login directory. (/home/robin)
Login shell path name, executed when the user logs in. (/usr/bin/sh)

The user can change the password by invoking passwd, the comment field (fifth field) with chfn, and the login program path name (seventh field) with chsh. The system administrator sets the remaining fields. The uid should be unique. See chfn(1), chsh(1), passwd(1), and passwd(4).

Eliminating Pseudo-Accounts and Protecting Key Subsystems

By tradition, the /etc/passwd file contains numerous “pseudo-accounts” — entries not associated with individual users and which do not have true interactive login shells.

Some of these entries, such as date, who, sync, and tty, evolved strictly for user convenience, providing commands that could be executed without logging in. To tighten security, they have been eliminated in the distributed /etc/passwd so that these programs can be run only by a user who is logged in.

Other such entries remain in /etc/passwd because they are owners of files. Programs with owners such as adm, bin, daemon, hpdb, lp , and uucp encompass entire subsystems, and represent a special case. Since they grant access to files they protect or use, these programs must be allowed to function as pseudo-accounts, with entries listed in /etc/passwd. The customary pseudo- and special accounts are shown in Figure 8-1 “Pseudo- and Special System Accounts”.

Figure 8-1 Pseudo- and Special System Accounts

root::0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:

The key to the privileged status of these subsystems is their ability to grant access to programs under their jurisdiction, without granting root access (uid 0). Instead, the setuid bit for the executable file is set and the effective user of the process corresponds to the owner of the executable file. For example, the cancel command is part of the lp subsystem and runs as effective user lp.

Once set, the security mediation of that subsystem enforces the security of all programs encompassed by the subsystem, not the entire system. Hence, the subsystem’s vulnerability to a breach of security is also limited to only that subsystem files. Breaches cannot affect the programs under different subsystems. For example, programs under lp do not affect those under daemon.

System Access by Modem

To protect against system penetration via modem, observe these precautions:

Require the use of a hardware dial-back system for all interactive modems.
Require an additional password from modem users, by adding an entry for the modem device in /etc/dialups and, optionally, /etc/d_passwd.
Have users renew their dial-in accounts frequently.
Cancel system access promptly when a user is no longer an employee.
Establish a regular audit schedule to review remote usage.
Connect the modems and dial-back equipment to a single HP-UX system, and allow network services to reach the destination system from that point.
Exceptions to dial-back must be made for UUCP access. Additional restrictions are possible through proper UUCP configuration. Another potential exception is file transfer via kermit. See kermit(1).
If a security breach with unknown factors occurs, shut down both network and telephone access and inform the network administrator.
To maximize security when configuring a dial-back modem system, dedicate the dial-out mechanism to the dial-out function only. It should not be configured to accept dial-in. Use another modem on another telephone line for your dial-in service.

Protecting Programs from Illegal Execution

As of HP-UX 11i, a new kernel parameter, executable_stack, allows you to prevent a program from executing code from its stack. This guards against an intruder passing illegal data to a program, causing the program to execute arbitrary code from its program stack.

By default, for backward compatibility, executable_stack is set to 1, which allows stack execution. You can use SAM to change the value to 0, preventing stack execution.

If a program does need to execute its stack, you can use the command

chatr +es enable program

to allow stack execution. See chatr(1) for details.