Commercial Security

10.x commercial security replaces the shadow passwd feature with new, more stringent security features.

New Features

Password management
You can set password length (up to 40 characters), delay between logins, maximum number of unsuccessful tries, lock account, etc.
Time-based access control.
You can restrict a user's login to certain times of the day or days of the week.
Location-based access control.
A user's login can be restricted to a particular terminal or host.

SVR4: getspent(3C)

getspent(3C) and the related calls getspnam(3C), endspent(3C), and setspent(3C) provide SVR4-conformant programmatic read access to shadow password-like entries for each user. They can be invoked only by a process that has superuser privileges.

setspent() and endspent() reset and end access to entries. getspent() returns the next entry, and getspnam() returns a particular entry based on login name.

These calls allow you to port code that uses SVR4-style shadow password files for reads. There are no equivalent routines for writes.

If you do not need SVR4 conformance, you can use getspwent and related routines instead, but you will need to link with libsec; see "Shadow Password Routines" in the "Compatibility with 9.x Releases" section of the Upgrading from HP-UX 9.x to 10.x manual.

New Commands, Calls and Files

Commercial Security has introduced a number of changes. Once you have 10.x on your system, see the manpages for details.

bigcrypt(1)
getprdfent(3)
getprpwent(3)
getprdvagent(3)
getprtcent(3)
iscomsec(3)
default(4)
prpwd(4)
devassign(4)
ttys(4)
authcap(4)

(See also lckpwdf(3C) and ulckpwdf(3C) in "New libc Routines at 10.0" in Chapter 9.

Old Features No Longer Supported

/.secure/etc/passwd (shadow password)

Applications accessing the shadow passwd file directly no longer worked as of 10.0.

getspwent(3), which relies on the shadow password file, has been rewritten to get its information from the new 10.x protected password database, and its external interface has not changed. Applications that accessed the shadow password file via this library call will still work, but they will need to be relinked on 10.x using libsec.




	NOTE: The shadow password routines that are in `libc` on 10.x no longer provide any functionality. They are stubs that allow applications that were linked with 9.x shared libraries to continue to work on 10.x non-trusted systems. 9.x executables that call these routines will not work on 10.x trusted systems, or on any 10.x system, trusted or non-trusted, if they were linked archived. See "Shadow Password Routines" in the "Compatibility with 9.x Releases" section of the Upgrading from HP-UX 9.x to 10.x manual for details.

The fgetspwent(3) and putspwent(3) calls.
These routines still exist in 10.x; they have been moved to libsec. But applications using them to read or update /.secure/etc/passwd will fail because the file no longer exists. See the 10.x getprpnam(3) manpage for replacement routines.

Commands, Calls, and Files Changed

Commercial Security has been modified. Once you have 10.x on your system, check the manpages for details.

login(1)         - added security behavior
passwd(1)        - added security behavior
su(1)            - added security behavior
passwd(4)
init(1M)         - added security behavior
getspwent(3)     - removed /.secure/etc/passwd processing
getpwent(3)      - see below

getpwent(3) routines will no longer return the password, audit ID, and audit flag in the password structure.

The interface remains the same, the returned structure remains the same, but the information is not returned. To obtain password and audit information, use getprpwent(3)

Password and Password Aging

If your 9.x trusted system has password aging, you should turn it off before upgrading to 10.01.

HP-UX 10.x uses a new password aging scheme for trusted systems. If a user account has no password aging, it will automatically use the system default, which is stored in the /tcb/files/auth/system/default file. The default values are a password lifetime of 28 weeks, and an expiration time of 26 weeks. You can change these values via SAM.

Users can also use SAM to set their own password aging. Individual password aging values are stored in the new 10.x protected password database, which contains a password file for each user.

The aging cycle for all passwords will be restarted when you upgrade a trusted system to 10.01.

The system default file does not allow null passwords. If any account has a null password, you must use SAM to provide one after you upgrade to 10.01.

Use pwck -s before upgrading to 10.01 to identify potential problems in /.secure/etc/passwd.

These changes affect only trusted systems; on non-trusted systems, any password aging established in /etc/passwd will remain in effect after you upgrade to 10.01.

Differences Between 9.x and 10.01

Your system will upgrade to 10.01 with security automatically turned on if the 9.x system is already secured.

You will notice the following changes on 10.x (see the previous topics for more details):

/.secure/etc/passwd is no longer supported.
Shadow password routines have been moved to libsec; the routines in libc are stubs.
getpwent(3) will no longer return the password, audit ID, and audit flag in the password structure.

For information on how these changes affect 9.x executables, see "Shadow Password Routines" in the "Compatibility with 9.x Releases" section of the Upgrading from HP-UX 9.x to 10.x manual.

When you secure a 10.x system (by choosing the security option in SAM), the following will happen:

The passwords will be removed from /etc/passwd and replaced by *, as in 9.x.
A set of default templates (or databases) will be put in place.
/tcb/files/auth/system/default
This is the system default file for each user and terminal.
/tcb/files/ttys
This is the terminal information file.
/tcb/files/devassign
This is the device information file. The only device supported in 10.x is the terminal. The only field is the list of users allowed on a given terminal.
A file will be created for every user in /etc/passwd.
This file contains the user's encrypted password, along with other information such as password aging, number of unsuccessful tries allowed, maximum password length allowed, times of day the user can log in, and so on.
The files are stored as:
/tcb/files/auth/[a-z,A-Z]/*
For example, information for user jane would be stored in /tcb/files/auth/j/jane
This file is also known as the protected password database.

Limitations

A 10.x secure system will not work in an NIS domain.
If placed in an NIS environment, a secure system could prevent everyone from accessing the secure system.
A 10.x secure system can coexist with the Distributed Computing Environment (DCE).
After logging in to the secured system a user can perform another dce_login and have access to DCE applications. But if DCE is explicitly installed on a secured system, then the login and password commands will be replaced by DCE versions that do not recognize the security attributes. In this case, system errors could occur.