| 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. 
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:
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 root@hpeos004[] echo "root\0\0\0\0sM" /usr/lbin/makekey sMnn9T.kL2Nuc root@hpeos004[] root@hpeos004[] root@hpeos004[] root@hpeos004[] echo "root\0\0\0\0sM" /usr/lbin/makekey sMnn9T.kL2Nuc root@hpeos004[] root@hpeos004[] root@hpeos004[] root@hpeos004[] echo "root\0\0\0\0sM" /usr/lbin/makekey sMnn9T.kL2Nuc root@hpeos004[] root@hpeos004[] root@hpeos004[] root@hpeos004[] echo "root\0\0\0\0sM" /usr/lbin/makekey sMnn9T.kL2Nuc root@hpeos004[] root@hpeos004[] root@hpeos004[] sM" /usr/lbin/makekey sMnn9T.kL2Nuc root@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[]
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. -
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: 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 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: 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: -
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. 
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 ! 29.2.3 The structure of the TCB 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. 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 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 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 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:\ :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[] 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 = 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. 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:
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]
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:
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  /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 | 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()) | | 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 | User-defined event 2 | | uevent3 | User-defined event 3 |
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 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[]
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 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[]
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 /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 [PRIALT<path>] Boot from specified path PAth [PRIALT] [<path>] Display or modify a path SEArch [DIsplayIPL] [<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. |
