29.2 HP-UX Trusted Systems

29.
2 HP-UX Trusted Systems
http://book.soundonair.ru/hall2/ch29lev1sec2.html
< Day Day Up >
29.2 HP-UX Trusted Systems

One of the primary motivations for moving to HP-UX Trusted Systems can be easily demonstrated with a standard HP-UX /etc/passwd file. By default, everyone needs read access to the /etc/passwd
file so we can equate UIDs with usernames; humans are never very good at remembering that UID=106 is a user called fred. Every time we want to communicate with fred, we use programs like mail
that look up fred's UID from the /etc/passwd file. Without this feature, using the system on a day-to-day basis would be virtually impossible. But therein lies the problem: If everyone can read an entry
from the /etc/passwd file, then they can read someone's password. The fact is that when we log in, the login/passwd program takes what we type as a password, encrypts it, and then compares it
with what is stored in the /etc/passwd file. If the comparison finds a match, we have typed the correct password and we are logged in. The clever part is trying to emulate the comparison technique
employed by the login/passwd commands. In fact, it's relatively simple. Figure 29-1 shows basically how the UNIX login/passwd process works; we take a plain-text password and encrypt it with an
encryption algorithm and an associated secret key.
Figure 29-1. Traditional UNIX password encryption.

[View full size image]
This is at the heart of the login/passwd process. These commands encrypt the password you type in and compare the result with the encrypted password in the /etc/passwd file. If the comparison finds
a match then you are allowed to login/change your password. At no time does UNIX decrypt the passwords stored in the /etc/passwd file. The fact that UNIX does not decrypt passwords is a very
good thing for security. If we take a look again at Figure 29-1, we can see a random element to the encryption process. This random component is known as a salt or a seed. It is random(ish) in that it is
based on the time of day and your current PID. This is used along with the encryption algorithm to generate the cyphertext from the plaintext password you type in. All looks fine up until now. The
problem is that the login/passwd process must EXACTLY match the encryption process when you login at some time in the future. If the salt/seed are truly random how can login/passwd process
recreate the random component? The answer is simple; the salt/seed are stored IN PLAIN VIEW in the /etc/passwd file. Some people get a little upset that I am telling the world the secrets of the UNIX
password algorithm. The rest of the world has known this for years. In fact, it's documented in the manual pages to the command /usr/lbin/makekey. The 13-character password stored in
/etc/passwd contains the two-character salt, and the remaining 11 characters constitute the remainder of the cyphertext of your encrypted password. Let's boil this down a bit by looking at an example.
Here's the password entry for the root user on one of my systems:
1 of 35
11/25/2015 12:11 AM
root@hpeos004[] pwget -n root

root:sM.XPxuSW7HSQ:0:3::/:/sbin/sh
root@hpeos004[]
The first two characters, sM, is the salt. Somehow I must generate matching cyphertext using a plain-text password, the salt, and the encryption algorithm. For my first attempt, I will use a password of
root. Here goes:
root@hpeos004[] echo "root\0\0\0\0sM" | /usr/lbin/makekey

sMnn9T.kL2Nucroot@hpeos004[]
root@hpeos004[]
root@hpeos004[]
I hope you can read the output = sMnn9T.kL2Nu. There's no match. The reason I have used four \0 characters is that /usr/lbin/makekey is expecting eight characters followed by the two-character
salt. This is effectively how commands like Crack work; they will try different well-known passwords, comparing the cyphertext with the entry in the /etc/passwd file. They then move on to any
sequence of the 64 characters' set of digits that can constitute a valid encrypted password. Eventually, they come up with an answer. In this case, if I persevere, I would come up with a string of
banana11. If I encrypt this text, I wonder what will happen?
root@hpeos004[] echo "banana11sM" | /usr/lbin/makekey

sM.XPxuSW7HSQroot@hpeos004[]
root@hpeos004[]
2 of 35
11/25/2015 12:11 AM
This produces cyphertext of sM.XpxuSW7HSQ, which is shown here in the entry in /etc/passwd:
root@hpeos004[] pwget -n root

root:sM.XPxuSW7HSQ:0:3::/:/sbin/sh
root@hpeos004[]
They match! We now know what the root password is.

This is not rocket science, but it does go to show why lots of flavors of UNIX employ what is called a shadow password file. HP-UX does not employ a shadow password file by default; until HP-UX 11i, we
have to configure trusted systems in order to implement a shadow password file.
NOTE: There is now a product call ShadowPassword available for HP-UX 11i that implements a file called /etc/shadow. This offers similar functionality to other versions of UNIX. You can integrate this file
with a LDAP solution, but it is not supported for NIS or NIS+. It is not supported for installations that rely on ObAM, e.g., the GUI interface for Partition Manager and Service Control Manager do not
support /etc/shadow. If you are using Cluster Object Manager for Serviceguard, you will need to upgrade to Serviceguard A.11.15.00 in order to use /etc/shadow. You can download ShadowPassword
free of charge from http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=ShadowPassword. By implementing ShadowPassword, we get the benefits of a
secure password file without needing to convert our system to a full-blown Trusted System. Because this is very new functionality for HP-UX, is supported only on HP-UX 11i, and does not offer as many
configuration possibilities as Trusted Systems, we mention it no further in this section.
HP-UX Trusted Systems is not only a shadow password file, it also enables lots of features that allow us to secure, monitor, audit, and customize a number of features relating to the login process
and where and when users can use the system.
29.2.1 Features of HP-UX Trusted Systems

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:
A free, bundled product with HP-UX.
Stores passwords in a protected password database.
Provides a flexible password aging mechanism.
Provides a greater control over users' password choices.
Time- and location-based access controls.
Single-user mode authentication.
Automatically disables accounts and terminals after repeated failed logins.
3 of 35
11/25/2015 12:11 AM
Flexible auditing whereby individual users can be audited down to the system call level.
This functionality does not come without a price. Here are some disadvantages of implementing Trusted Systems:
Incompatible with NIS.
Incompatible with applications that directly modify /etc/passwd.
Increased complexity.
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:
"Trusted Computing Base (TCB)-The totality of protection mechanisms within a computer system-including hardware, firmware, and software-the combination of which is responsible for
enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a trusted computing base to
correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance)
related to the security policy."
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):
Division D: Minimal protection
This division contains only one class. It is reserved for those systems that have been evaluated but fail to meet the requirements for a higher evaluation class.
Division C: Discretionary security protection
- Class C1: Discretionary security protection
The Trusted Computing Base (TCB) of a class C1 system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form
of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep
other users from accidentally reading or destroying their data. The class C1 environment is expected to be one of cooperating users processing data at the same level(s) of sensitivity.
- Class C2: Controlled access protection
Systems in this class enforce a more finely grained discretionary access control than C1 systems, making users individually accountable for their actions through login procedures, auditing
of security-relevant events, and resource isolation.
Division B: Mandatory protection
- Class B1: Labeled security protection
Class B1 systems require all the features required for class C2. In addition, an informal statement of the security policy model, data labeling, and mandatory access control over named
4 of 35
11/25/2015 12:11 AM
subjects and objects must be present. The capability must exist for accurately labeling exported information. Any flaws identified by testing must be removed.
- Class B2: Structured protection
In class B2 systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found
in class B1 systems be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and
non-protection-critical elements. The TCB interface is well defined, and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review.
Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration
management controls are imposed. The system is relatively resistant to penetration.
- Class B3: Security domains
The class B3 TCB must (1) satisfy the reference monitor requirement that it mediate access of subjects to objects, (2) be tamperproof, and (3) be small enough to be subjected to
analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and
implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery
procedures are required. The system is highly resistant to penetration.
Division A: Verified protection
- Class A1: Verified design
Systems in class A1 are functionally equivalent to those in class B3 in that no additional architectural features or policy requirements are added. The distinguishing feature of
systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly
implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping
with the extensive design and development analysis of the TCB required of systems in class A1, more stringent configuration management is required and procedures are
established for securely distributing the system to sites. A system security administrator is supported.
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:
Identification and Authentication
Administration of Rights
Verification of Rights
Audit
Object Reuse
Error Recovery
Continuity of Service
Data Communication Security
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.
5 of 35
11/25/2015 12:11 AM
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:
Enabling and disabling HP-UX Trusted System functionality
The structure of the TCB
Password Policies, Aging, and Password History Database
Time- and Location-based access controls
Auditing users, events, and system calls
Boot Authentication
We will configure these features for individual users as well as for the system as a whole, where relevant. Let's get started.
29.2.2 Enabling and disabling HP-UX Trusted System functionality

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.

[View full size image]
6 of 35
11/25/2015 12:11 AM
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...
7 of 35
11/25/2015 12:11 AM
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
8 of 35
11/25/2015 12:11 AM
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!
29.2.3 The structure of the TCB
9 of 35
11/25/2015 12:11 AM
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[]
10 of 35
11/25/2015 12:11 AM
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.
29.2.3.1 FORMAT OF A TCB FILE

All the files within the TCB are ASCII files. All files follow a similar structure. Each file is effectively a single line. The entry is referenced via the first token on the line known as the name. The name and
subsequent capabilities are separated by a colon (:) character. Each entry can have 0 or more capabilities. At the end of the line is a checkent field that must exist; otherwise, all authentication routines
will reject the entry in its entirety. Here's the example of the entry for root again:
root@hpeos004[] cat /tcb/files/auth/r/root

:u_pwd=RNeo9DPApktR.:\
:u_auditflag#1:\
:u_pswduser=root:u_suclog#1065192971:u_lock@:chkent:
root@hpeos004[]
The name is root, as you would expect. We have a series of capabilities, and finally we have the checkent field. The name, capabilities, and checkent field are each terminated by the colon (:) character.
Without this basic structure, the entry is deemed invalid and ignored. The capabilities all have a unique name and can be numeric, Boolean, or string values.
Numeric values are of the form: id#num.
Boolean expressions are of the form: id or id@.
The reason for two forms is the necessity for the expression to be either true or false. If the capability is present and of the form id, then it is true. If the capability is has the @ symbol appended
to it, i.e., of the form id@, then it is false.
String expressions are of the form: id=string.
If a capability is not explicitly listed, it will assume the default behavior for that capability as specified in the system-wide defaults file /tcb/files/auth/system/default. Be careful that you understand
11 of 35
11/25/2015 12:11 AM
the default behavior for particular capabilities as specified in the default file before removing capabilities from a particular database file.
29.2.3.2 THE TTYS, DEVASSIGN, AND OTHER TCB FILES

The TCB maintains a single terminal control database. The file is called /tcb/files/ttys. Entries in this file control whether login is allowed to a particular terminal, i.e., whether a terminal is locked.
Additional capabilities relate to delays between login attempts, login timeouts, and the maximum number of login attempts allowed before the terminal is locked. These attributes usually relate to directly
connected terminals and modems. Locking a pseudo-terminal device file makes little sense because we don't know who, if anyone, will attempt to log in via a particular pseudo-terminal. Additional
information is maintained in this file relating to who lasted logged in to the terminal, when he logged in, and the when the last unsuccessful login attempt was made.
The /tcb/files/devassign file is known as the device assignment database or the terminal control database. As the name suggests, we can assign devices to particular users; the devassign file
controls which users can use particular terminal/modems. If users are not listed against a specific device, everyone can use that device. As with the ttys file, we normally don't list pseudo-terminal device
files in the devassign file.
29.2.4 Password policies, aging and password history database

We can control many aspects of a user's password including the following:
Who generates the password
The format of the password
The maximum length of the password
When passwords expire
Using a password history database to avoid users from using a restricted list of passwords
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:\
12 of 35
11/25/2015 12:11 AM
: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:
13 of 35
11/25/2015 12:11 AM
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
14 of 35
11/25/2015 12:11 AM
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[]
29.2.5 Time- and location-based access controls

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 =
15 of 35
11/25/2015 12:11 AM
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
char
50
fd_tod[AUTH_TOD_SIZE];
/* length of time-of-day constraints */

/* 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:
16 of 35
11/25/2015 12:11 AM
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.
29.2.6 Auditing users, events, and system calls

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:
Audit has a direct and in some cases a dramatic effect on system performance because every eligible event or system call will be monitored and logged to an audit log file.
You have to set aside significant disk space to keep recent audit log files.
You need to manage the disk space set aside for audit log files carefully. Processes can become blocked if there is no available disk space for audit records and a process makes a call to an
audited system call or event.
You need to monitor audit log file at least daily to establish a picture of what is happening on your system. This picture of activity can be used to customize the events and system calls that you
are auditing. This process of reevaluation should be a continuous one.
Ensure that you have the most recent patches for the auditing subsystem. Being a deeply embedded subsystem, any problems can cause major problems. (My 11i system from March 2003
media has suffered a system PANIC while using VxFS ACLs on a system with auditing enabled. Turn off auditing, and the VxFS ACLs behave as normal.)
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.
29.2.6.1 SETTING UP AUDIT LOG FILES

Let's look at the startup configuration file that deals with auditing:
17 of 35
11/25/2015 12:11 AM
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.
18 of 35
11/25/2015 12:11 AM
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%)
19 of 35
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
11/25/2015 12:11 AM
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]
First, we need to change the AUDITING variable to equal 1 in order to turn on auditing. In doing so, we turn on auditing for all users (u_auditflag#1 in user specific protected password database files) for
the events of moddac (MODify Discretionary Access Control information = chmod, chown, and so on), admin (ADMINistrative and superuser activities, e.g., rtprio, reboot, swapon, hostname, and so on)
and login (login, believe it or not). This in itself generates a significant amount of data. The data is stored in one of two audit logfiles. If we look at the startup configuration file, both files are stored in
the directory /.secure/etc and are called audfile1 and adufile2. When you understand why we have two audit logfiles, you realize that you cannot continue with this configuration.
We have two audit logfiles in case the first audit logfile fills up. When we say "filling up," we are talking about a size whereby the auditing system will switch to the second audit logfile. The name and size
of both audit logfiles is specified in the startup script via the variables:
20 of 35
11/25/2015 12:11 AM
PRI_AUDFILE=/.secure/etc/audfile1
PRI_SWITCH=1000
SEC_AUDFILE=/.secure/etc/audfile2
SEC_SWITCH=1000
The size is specified in kilobytes. The name and size of the files is also stored in the file /.secure/etc/audnames. The command audsys will read the audnames file at startup, if it exists. If the audnames file
doesn't exist, the audsys command will use the parameters in the startup configuration file. These file sizes set up a switch point known as the AuditFileSwitch (AFS). There is a second switch point known
as the FileSpaceSwitch (FSS), which deals with the percentage of available disk space in the filesystem where the first audit logfile resides. When auditing is started, a process known as the audit overflow
monitor daemon (audomon, see the AUDOMON_ARGS in the startup file above) monitors the FSS and AFS switch points every minute (-t 1). The AFS switch point is set by default to 20 percent (-p 20) of
available disk space. If either switch point is reached, audomon will switch to a second audit logfile if available. Warning messages are sent to the system console when we are 90 percent (-w 90) of the
way to reaching either switch point. If that second logfile resides in the same filesystem, it won't be long before the filesystem fills up and we cannot log any more auditing information. That's why we
need to change the default configuration if both audit logfiles reside in the same filesystem. It's probably a good idea to have both audit logfiles in separate mountable filesystems (ensure that the location
is readable and writeable only by root). When you decide where to put your audit logfiles, be sure to update the /etc/rc.config.d/auditing and the /.secure/etc/audnames files. I have set up two
separate filesystems, each containing an audit logfile:
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[]
Once you have set up the auditing startup file and the audnames file, the easiest way to implement your changes would be to stop auditing (audsys -f) and rerun the auditing startup script; however, this
does stop auditing, which is not entirely desirable. If you want to make online changes to the audit logfile configuration, you will need to run an audsys command that reflects those changes:
root@hpeos004[etc] audsys -c /auditing/audfile1/audfile1 -s 97280 -x /auditing/audfile2
21 of 35
11/25/2015 12:11 AM
/audfile2 -z 97280
root@hpeos004[etc]
We are now ready to look at which users, events, and system calls we want to audit.
As we said earlier, all users are audited by default. To turn off auditing for a specific user, we use the audusr command:
root@hpeos004[] audusr -d fred

root@hpeos004[]
This turns off auditing for that user and sets the u_auditflag capability to 0 (zero) in the user's protected password database file. We can simply use the -a to audusr to turn auditing back on.
Remember that the default is to include root as an audited user and the events of moddac, admin, and login as selected by default. We audit for the success as well as the failure of these events. This
generates a significant amount of audit data. Adding additional events and system calls only increases the amount of data produced.
Choosing the list of events and system calls to audit is tricky. You need to decide what are important events and whether to audit for a success, a failure, or both. This is a tricky question; if someone
runs the rtprio command, are you interested when it is a success or a failure? Some people would say that if all other aspects of system security are sufficient, then we would only be interested in
failures. My response is that I would never be so bold as to assume that my system security was always completely watertight and I would probably audit for both success and failure.
Table 29-1. Audit Event and System Calls
22 of 35
Event
Associated system call(s), if any
create
Object creation (creat(), mkdir(), mknod(), msgget(), pipe(), semget(), shmat(),

shmget())
delete
Object deletion (ksem_unlink(), mq_unlink(), msgctl(), rmdir(), semctl(), shm_unlink())
readdac
Discretionary access control (DAC) information reading (access(), fstat(), fstat64(),

getaccess(), lstat(), lstat64(), stat(), stat64)
moddac
Discretionary access control (DAC) modification (acl(), chmod(), chown(), fchmod(),

fchown(), fsetacl(), lchmod(), lchown(), putpmsg(), semop(), setacl(), umask())
modaccess
Non-DAC modification (chdir(), chroot(), link(), lockf(), lockf64(), rename(), setgid(),

setgroups(), setpgid(), setpgrp(), setregid(), setresgid(), setresuid(), setsid(), setuid(),
shmctl(), shmdt(), symlink(), unlink())
11/25/2015 12:11 AM
Event
Associated system call(s), if any
open
Object opening (execv(), execve(), ftruncate(), ftruncate64(), kload(), ksem_open(),

mmap(), mmap64(), mq_open(), open(), ptrace(), shm_open(), truncate(), truncate64())
close
Object closing (close(), ksem_close(), mq_close(), munmap())
process
Process operations (exit(), fork(), kill(), mlock(), mlockall(), munlock(), munlockall(),

nsp_init(), plock(), rtprio(), setcontext(), setrlimit64(), sigqueue(), ulimit64(), vfork())
removable
Removable media events (exportfs(), mount(), umount(), vfsmount())
login
Logins and logouts
admin
administrative and superuser events (acct(), adjtime(), audctl(), audswitch(),

clock_settime(), mpctl(), reboot(), sched_setparam(), sched_setscheduler(), serialize(),
setaudid(), setaudproc(), setdomainname(), setevent(), sethostid(), setpriority(),
setprivgrp(), settimeofday(), stime(), swapon(), toolbox(),utssys())
ipccreat
Interprocess Communication (IPC) object creation (bind(), ipccreate(), ipcdest(), socket(),

socket2(), socketpair())
ipcopen
IPC object opening (accept(), connect(), fattach(), ipcconnect(), ipclookup(), ipcrecvcn())
ipcclose
IPC object deletion (fdetach(), ipcshutdown(), shutdown())
ipcdgram
IPC datagram (sendto() and recvfrom())
uevent1
User-defined event 1
uevent2
uevent3
The user-defined events allow application developers to include calls to the audswitch() and audwrite() system calls. There are no hard and fast rules as to which events are good or bad to include.
You really need to analyze the use of your system and work out what is normal behavior. From that, you can decide either to continue to monitor normal behavior or to include deviations from the norm.
To add an event to be audited, we use the audevent command. Here, I am auditing for a success (-P) and a failure (-F) for the ipcclose event:
root@hpeos004[] audevent -P -F -e ipcclose

root@hpeos004[] audevent -E
23 of 35
event:
moddac: success failure
event:
login: success failure
event:
admin: success failure
11/25/2015 12:11 AM
24 of 35
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
11/25/2015 12:11 AM
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[]
25 of 35
11/25/2015 12:11 AM
I need to remember to update the /etc/rc.config.d/auditing file. I would update one of the AUDEVENT_ARGS variables to include the arguments I just used on the command line.
A good practice is to ensure that you back up as well as read your audit logfile on a regular basis. If both the primary and audit logfile are full, there is no next audit logfile, and a process generates an
auditable event or system call, that process will be blocked until we can resolve that situation. You can log in to the console and manage the situation. If you have to zero length the audit logfile, it is a
good idea that we take a backup of it to maintain our audit trail.
To display audit events, we use the audisp command. Here, I am displaying the successful (-p) calls to the chown system call (-c chown) between the hours of 20:00 on 3 October and 21:00 on 4
October:
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
TIME
4 21:00:00 2003
PID E
EVENT
PPID
AID
RUID
RGID
EUID
EGID TTY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:22:38
6538 S
16
6537
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=bin;
2 ???
RETURN_VALUE 1 = 0;
26 of 35
11/25/2015 12:11 AM
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
[ Event=chown; User=root; Real Grp=sys; Eff.Grp=sys;
3 ???
RETURN_VALUE 1 = 0;
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
3 ???
RETURN_VALUE 1 = 0;
0x40000003 (dev);
5215 (inode);
(path) = /.Xauthority
PARAM #2 (int) = 0
27 of 35
11/25/2015 12:11 AM
PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:28:09
6655 S
16
6628
3 ???
RETURN_VALUE 1 = 0;
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
2 ???
RETURN_VALUE 1 = 0;
0x00000001 (dev);
1493 (inode);
(path) = /dev/pts/0
PARAM #2 (int) = 0
PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
031004 19:32:35
6881 S
16
6880
28 of 35
2 ???
11/25/2015 12:11 AM
RETURN_VALUE 1 = 0;
0x00000001 (dev);
1494 (inode);
(path) = /dev/pts/1
PARAM #2 (int) = 0
PARAM #3 (int) = 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
root@hpeos004[]
You can see the username logged against every log record. Auditing uses the user's audit ID to record actions because a TCB guarantees that each user is uniquely identifiable. A traditional UNIX system
cannot guarantee this because two users can have the same user ID. Before you start saying that we could manipulate the audit ID to have two users with the same audit ID, I know that. But then you
would be in contravention of the TCB and your Trusted System is null and void. The audit ID has nothing to do with your user ID. The audit ID is stored in the protected password database.
As you can see, even this restrictive look at my logfile can produce a significant amount of data. We need to check our logfiles regularly. Don't always look for the same things or around the same
timeframes because you may be missing something important! It may be that you develop some script or program to automate and annotate these logfiles from their current format. Just make sure
that you back them up regularly, review them regularly, and adopt a suspicious or hacker-attitude to try to uncover security-relevant tasks that contravene company IT policies.
29.2.7 Boot authentication

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
29 of 35
11/25/2015 12:11 AM
/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
:u_pwd=XfxOmormowsLk:\
:u_auditflag#1:\
30 of 35
11/25/2015 12:11 AM
: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:
31 of 35
11/25/2015 12:11 AM
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 --------------------------------------------------------------
32 of 35
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
11/25/2015 12:11 AM
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.

...
33 of 35
11/25/2015 12:11 AM
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
34 of 35
11/25/2015 12:11 AM
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.
< Day Day Up >
35 of 35
11/25/2015 12:11 AM

29.2 HP-UX Trusted Systems

Uploaded by

Copyright:

Available Formats

29.2 HP-UX Trusted Systems

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

29.2 HP-UX Trusted Systems

Uploaded by

Copyright:

Available Formats

29.

2 HP-UX Trusted Systems

< Day Day Up >