Administering Your HP-UX Trusted System HP 9000 Computer Systems ABCDE HP Part No.
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and tness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty.
c copyright 1979, 1980, 1983, 1985-93 Regents of the University of California This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California. c copyright 1980, 1984, 1986 Novell, Inc. c copyright 1986-1992 Sun Microsystems, Inc. c copyright 1985-86, 1988 Massachusetts Institute of Technology. c copyright 1989-93 The Open Software Foundation, Inc. c copyright 1986 Digital Equipment Corporation. c copyright 1990 Motorola, Inc.
Printing History The manual printing date and part number indicate its current edition. The printing date will change when a new edition is printed. Minor changes may be made at reprint without changing the printing date. The manual part number will change when extensive changes are made. Manual updates may be issued between editions to correct errors or document product changes. To ensure that you receive the updated or new editions, you should subscribe to the appropriate product support service.
Preface This manual describes tasks required for con guring and administering an HP- UX system as a C-2 level trusted system. This manual is for system administrators with superuser privilege and should be restricted to those with the proper authority.
Conventions Used in this Manual This manual uses the following typographic conventions: Boldface Words in boldface are terms de ned for the rst time. Underlined Computer Underlined computer font indicates items you type. For example: /usr/sbin/newfs Computer Italics 4Return5 ... vi Computer font within text indicates HP-UX commands, utilities, and SAM menu items. Italics indicates manual titles, emphasized words, parameters to an HP-UX command, and entries in the HP-UX Reference .
Contents 1. Description of the HP-UX Trusted System Background Required . . . . . . . . . . . . . . . . What is a Trusted System? . . . . . . . . . . . . . . What is C2-Level Trusted Mode? . . . . . . . . . . . Parts of the TCB . . . . . . . . . . . . . . . . . Excluded from the TCB . . . . . . . . . . . . . . TCB Interface . . . . . . . . . . . . . . . . . . Trusted System Administration . . . . . . . . . . . . System Administration Manager . . . . . . . . . . Trusted Computer System Evaluation Criteria .
2. Installation and Con guration of an HP-UX Trusted System Information about Installing or Upgrading HP-UX . . . . . Conversion Prerequisites . . . . . . . . . . . . . . . . . Setting Secure Mode on Workstations . . . . . . . . . . Preventing Access to ISL and the System Console on Servers Obtaining Security Patches . . . . . . . . . . . . . . . Obtaining Non-Security Patches . . . . . . . . . . . . Verifying and Replicating Your System Con guration . . . . Setting Up Your C2-Level Trusted System . . . . .
Entries in the Protected Password Database Selecting and Generating Passwords . . . . Password Aging . . . . . . . . . . . . . Time-Based Access Control . . . . . . . Device-Based Access Control . . . . . . . Device Assignment Database . . . . . . Terminal Control Database . . . . . . . Manipulating the Trusted System Databases Account and Terminal Lock Flags . . . . . . Changing the Owner of a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A. Audit Record Format Audit Records . . . . . . . . . . System Call Audit Record Format Self-Auditing Audit Record Format Self-Auditing Commands . . . . chfn(1) . . . . . . . . . . . chsh(1) . . . . . . . . . . . login(1) . . . . . . . . . . . newgrp(1) . . . . . . . . . . passwd(1) . . . . . . . . . . audevent(1M) . . . . . . . . audisp(1M) . . . . . . . . . audsys(1M) . . . . . . . . . audusr(1M) . . . . . . . . . fbackup(1M) . . . . . . . . . B. Commands and System Calls C.
Tables 1-1. 1-2. 2-1. 2-2. B-1. TCSEC C2-Level System Features . . . . . . . . . . . . Trusted Facility Manual Information Mapping . . . . . . . Audit Event Types and System Calls . . . . . . . . . . . Library Routines for Manipulating Trusted System Databases Commands and System Calls . . . . . . . . . . . . . . .
1 Description of the HP-UX Trusted System The Hewlett-Packard C2-level trusted system consists of the HP-UX Release 10.10 operating system con gured in trusted mode and its commands, utilities, and subsystems along with supported hardware. This results in a system designed to meet the criteria of a C2-level trusted system, as described in Section 2.2 of the Department of Defense Trusted Computer System Evaluation Criteria , DOD 5200.
Background Required To e ectively use this manual and to be able to ensure your system's security, you should be familiar with HP-UX system administration as described in HP-UX System Administration Tasks .
What is C2-Level Trusted Mode? You can con gure HP-UX in either the C2-level trusted mode or the untrusted mode. For the purposes of this chapter, the HP-UX trusted system being de ned is one which is con gured in the C2-level trusted mode. In the untrusted mode, HP-UX o ers the security mechanisms available in the standard UNIX environment.
in secure multiuser mode. This includes both the trusted and untrusted portions of the HP-UX operating system. Some of the trusted commands and utilities in the TCB can cause the system to leave its secure state (for example, to shutdown or reboot the system). The TCB also includes sam (1M), HP's System Administration Manager. Refer to \System Administration Tasks" later in this chapter for more information on SAM. Security-related commands and system roles are listed in Appendixes B and C.
Note Users can write programs that bypass the system call interface and invoke trap instructions directly. All system security policy decisions are made in kernel code that is accessible only through invocation of the trap instruction. All user actions that involve policy decisions must eventually go through the trap interface. Therefore, system security policy cannot be violated or bypassed.
System Administration Manager HP's System Administration Manager, sam (1M), is included as part of the TCB in a C2-level trusted HP-UX system. SAM provides an easy-to-use interface for performing setup and other essential system administration tasks. Note SAM can only be used in character mode in a trusted system. By default, only the superuser can use sam (1M). The superuser may optionally set up a restricted sam (1M) to allow particular users to administer speci c functional areas of sam (1M).
Features are visible functions that carry out the security policy of a system. Assurances are tasks that the system implementor must complete to guarantee that the system meets speci cations. HP-UX complies with (and in many instances exceeds) the TCSEC requirements for the C2 class. Table 1-1 summarizes the TSCEC features and assurances that must be satis ed by a C2-level trusted system.
Discretionary Access Control Using discretionary access control (DAC), owners of objects containing data can allow or deny access to these objects at their own discretion, on a need- to-know basis. Objects are things such as les, devices, or interprocess communications mechanisms that another user or the user's process is attempting to access. Users of standard HP-UX systems protect objects, such as les, by establishing read, write, and access permissions to these objects.
The C2-level of trusted HP-UX uses standard HP-UX mechanisms to clear newly allocated disk blocks and memory pages. It extends standard mechanisms for authentication to clear bu ers containing passwords immediately after they are encrypted. Identification and Authentication The TCSEC requires users to identify themselves to the TCB before performing any actions that the TCB must mediate. The TCB will maintain data to verify the identity of individual users, thus authenticating each user.
Audit In a trusted system, all users are held accountable for their actions. That is, any security-relevant action must be traceable to a particular responsible user. Some features of standard HP-UX make accountability di cult because some actions (such as those performed by pseudo-user accounts like lp or cron ) cannot be traced to a speci c user. The HP-UX C2-level auditing subsystem logs security-related events to ensure user accountability.
System Architecture The system needs to be organized in such a way that the areas requiring protection can be isolated from the rest of the system. In this way, access to these areas can be controlled, monitored, audited, and protected from unauthorized access. System Integrity The enforcement of security must be extended to system hardware and software features so that correct operation of the system can be veri ed.
System Security Policy The system enforces a security policy which is a combination of mode permission bits and access control lists. The policy can be stated, in real world terms, as follows: A person may read a document if: (1) the person owns the document, (2) if the document's owner allows him or her to, (3) if the person is a member of a group which owns the document and group read permission is set, or (4) if read permission of the document is universally granted.
Approaching System Security Following are steps to perform as a general approach to system security: Identify what you need to protect. These are your assets such as employees, system hardware, data (onsite and o site), and documentation. Identify potential threats to your assets. These include threats from nature ( oods, earthquakes), ignorance and lack of training, and intentional security breaches. Implement measures that will protect your assets in a cost e ective manner.
procedures for examining and maintaining audit trails, and other system administration tasks. Security Features User's Guide The information required for the Security Features User's Guide is aimed at end users. Information must describe system protection mechanisms such as those for le and account protection and provide general security guidelines. The following documents provide the information required for the Security Features User's Guide .
Trusted Facility Manual This manual, Administering Your HP-UX Trusted System , is part of a set of HP-UX manuals that provide the information required in the Trusted Facility Manual. This manual is a pointer to other documents that make up the TFM. The information is all of these documents should be consistent, however, if di erences exist this manual contains the most current information.
Table 1-2.
Table 1-2.
Table 1-2.
Table 1-2.
E3/FC2 ITSEC Security Certification HP-UX 10.10 has been certi ed as meeting the E3/FC2 level of security under the Information Technology Security Evaluation Criteria (ITSEC) of the European Community. This certi cation validates the commercial security functionality of HP-UX. The following con guration must be installed and maintained for your system to match the system which was evaluated to the ITSEC criteria and to comply with the ITSEC certi cation: HP-UX Release 10.
PHCO 6641 PHCO 6705 PHCO 6712 PHCO 6770 PHCO 6772 PHCO 6777 PHCO 6820 PHCO 6821 PHC0 6839 PHCO 6875 PHCO 7031 PHCO 7032 PHCO 7035 PHCO 7046 PHCO 7115 PHCO 7171 PHCO 7271 PHCO 7466 PHCO 6573 PHCO 6920 PHCO 7120 PHC0 7246 PHCO 7257 PHCO 7258 PHCO 7259 PHCO 7394 Description of the HP-UX Trusted System 1-21
PHCO 7370 PHCO 7663 PHKL 7359 PHNE 6068 PHNE 6444 PHNE 6688 PHNE 6815 PHNE 6919 PHNE 6961 PHNE 6983 PHNE 6990 PHNE 7020 PHNE 7076 PHNE 7087 PHNE 7108 PHNE 7433 PHSS 6403 PHSS 6469 PHSS 6510 PHSS 6577 PHSS 6580 PHSS 6582 PHSS 6617 PHSS 6622 PHSS 7013 And for the Series 800: 1-22 Description of the HP-UX Trusted System
PHCO PHNE PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL PHKL 6820 7355 6777 6573 6920 7120 7246 7257 7258 7259 7370 7394 7663 6485 6487 6663 6676 6681 6717 6791 7018 7056 7163 7335 7459 7616 Description of the HP-UX Trusted System 1-23
PHNE PHNE PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHCO PHKL PHNE PHNE PHNE PHNE PHNE PHNE PHNE PHNE PHNE PHNE PHNE 1-24 6317 4450 5400 6641 6770 6839 6875 7031 7032 7046 7115 7171 7271 7466 7359 6068 6444 6815 6969 6961 6983 6990 7020 7077 7088 7108 Description of the HP-UX Trusted System
PHNE 7433 PHSS 6403 PHSS 6469 PHSS 6510 PHSS 6577 PHSS 6580 PHSS 6582 PHSS 6617 PHSS 6622 PHSS 7013 Networking not con gured and the system not connected to a network Con gured in Trusted Mode Auditing enabled HP-VUE and X-Windows disabled Restricted SAM not used HP-UX 10.10 was certi ed in a resticted con guration. Networking was not con gured and the system was not connected to a network. HP-VUE and X-Windows were disabled, and Restricted SAM was not used.
Installation and Configuration of an 2 HP-UX Trusted System This chapter describes information that relates to the installation and con guration of an HP-UX system in preparation to converting the system to a C2-level trusted system. This chapter does not include all of the details needed to install your system. That information is provided in other documents to which this chapter refers for more information.
Information about Installing or Upgrading HP-UX HP-UX systems include system con guration logs which describes the current con guration of the system. They are in /var/adm/su/ . If you change the system by installing or upgrading it, you should maintain the information in the log and keep it up to date. Log all changes and keep that information for future reference.
10.10. The package includes the manual Upgrading from HP-UX 9.x to 10.x , which explains the upgrade process. Conversion Prerequisites Before you can convert your system into a C2-level trusted system, the following prerequisites must be met: You have set SECURE to ON in the ISL when rst booting your workstation. The steps are described in the following section. Your system must be running HP-UX Release 10.10.
Setting Secure Mode on Workstations Before allowing users on a workstation, you must set SECURE to ON at the ISL prompt. This is the prompt you can receive when the system is booting. This prevents users from having access to the ISL prompt. This action is needed to insure the security and integrity of the hardware. In order to enable secure mode: 1. Interrupt the boot sequence (by pressing Escape) and at the BOOT ADMIN> prompt. 2.
To retrieve the index of all HP Security Bulletins issued to date, send the following in the text portion of an email message: send security_info_list To get a patch matrix of current HP-UX and security patches referenced by either Security Bulletin or Platform/OS, put the following in the text of the email message: send hp-ux_patch_matrix You can view additional information on the World Wide Web at the URL: http://us.external.hp.com Choose \Support news" then \Security Bulletins.
Verifying and Replicating Your System Configuration HP-UX maintains several very important records of your system installation and modi cation. These log les document how you installed and con gured your system and are critical in the event you have to reconstruct your original con guration. These les are located in /var/adm/sw/ Immediately after completing your installation, you should save these les. You should copy them to tape or make a hard copy.
2. Install anti-tamper devices on all workstations that will be included in the trusted system con guration. 3. Inspect all existing les on your system for security risks and remedy them. This is mandatory the rst time you convert to a trusted system. Thereafter, examine your les regularly, or when you suspect a security breach. 4. Change your workstation to character mode by typing: unset display 5. Convert to a trusted (secure) system: a. Type SAM (in character mode): sam The SAM main menu is displayed.
Note The system displays a warning message about ACLs not being supported on a VxFS system. This is because JFS systems (VxFS) do not support ACLs, an integral part of discretionary access control. JFS is not part of the TCB and you cannot con gure JFS systems as trusted systems. The system displays the following message: Converting to a trusted system.... Successfully converted to a trusted system. Press OK to continue. The conversion program does the following: a.
The Audited Events screen is displayed. It includes a table of events that can be audited, speci cations on how the events are to be audited (on success, failure), and lists system calls associated with each event. On the screen you should see the message: Auditing Turned Off If Auditing is Turned On, your system is already converted to a trusted system. Do not proceed with the rest of these steps. 7. Click on any of the events to be audited.
Verifying Setup There are several log les you can check to verify the con guration of your system. Check the SAM log, installation log, and SD-UX log for this information. It is important that you also maintain information on the system con guration in the System Support Log which is supplied with your system. You should keep a record of all pertinent information including: root disk selection, le system layout, swap size, and lename length. This information can be recorded in the System Support Log.
Administering Auditing As system administrator, you are responsible for administering auditing and performing the following tasks: Setting up the auditing subsystem parameters Selecting event types and other selection criteria for generating auditing information Performing reduction and analysis of the audit trail Maintaining online and o ine audit trail data Planning le system space consumption for audit data Coordinating disk space requirements and user-speci c audit parameters The audit subsystem lets y
and maintains the names of the auditing les in the /.secure/etc/audnames le. When you start auditing, the audomon daemon starts to monitor the audit les. Thereafter, audomon is typically spawned by /sbin/init.d/ auditing as part of the init (1M) startup process when the system is booted. Refer to the HP-UX Reference or system man pages for more information on the auditing commands. Turning On Auditing Auditing must be turned on for normal system operation on a trusted system.
Selecting Events to Audit Continue by selecting what you want to audit: 1. Select the event types you want to audit. You can audit selected events on success, failure, on both success and failure. Tab to the menus, select the Actions menu and choose the appropriate action: a. Audit for Success Only b. Audit for Failure Only c. Audit for Both Success and Failure d. Audit for Neither Success nor Failure 2. From the List menu, select Audited System Calls. Select the system calls you want to audit.
Default Auditing Parameters The system supplies default auditing parameters when auditing is turned on. Some of the defaults are activated automatically, others have to be enabled. By default, the audit status for all users is set to y. New users added to the system are automatically audited. According to C-2 level requirements, all users must be individually accountable for their actions from login until exit. The event types admin, login, and moddac are selected as defaults by the system.
Note We recommend that the primary and auxiliary audit log les reside on separate le systems. You must specify the path name of a new (or empty) le for the audit log le; otherwise, the contents of the le will be deleted.
Table 2-1.
Table 2-1.
occur are recorded in the audit trail. Full auditing consumes a large amount of disk space, however. You can also postselect audited events, examining only those records that are of interest. This lets you examine the audit trail based on event types, user IDs, group IDs, object names, or whatever criteria you nd useful. Some privileged programs are given the capability to self-audit. Self- auditing programs suspend system call auditing of themselves and write their own audit records.
6. Select OK. Processes that perform a security-relevant event generate an audit record . Audit records are generated as a result of a user initiating a system call or due to a self-auditing program through a call to audwrite (2). Audit records are classi ed into di erent audit event types as shown previously in Table 2-1. As audit records are generated, they are written to the primary audit le. Audit les are located in /.secure/etc/audfile*.
Reducing and Analyzing the Audit File Auditing accumulates a lot of data. SAM allows you to select which data to view. You can select the following items: Whether the log output is directed to the screen or to a le The name of the le to which log output is to be directed Whether to view successful or failed events Which log le to view Which tty to view Which events or system calls to view Viewing the Audit File To view the audit le: 1. Run SAM: sam 2. 3. 4. 5. 6. 7. The SAM main menu is displayed.
d. TTYs e. Time Interval 8. Highlight Select to select particular items to audit. 9. Select OK. Once you have speci ed the items to view, it may take a few minutes to prepare the report for viewing, especially if you are working with a very large audit le. Then the audit le is displayed. Analyzing the Auditing Data When viewing auditing data, be aware of the following: Auditing data may be inaccurate when programs that call auditable system calls supply incorrect parameters.
See \Guidelines for Administering Auditing" in Chapter 3 for information. Refer to HP-UX Administration Tasks for additional guidelines for administering your auditing system. Planning Sufficient Disk Space for Auditing Data Note Note Auditing must be turned on for normal system operation on a trusted system. If you need to turn auditing o to perform system administrative functions, bring the system into single user mode, turn auditing o , then perform the desired operations.
make sure that auditing is on after a reboot and before you bring the system back into multi-user mode Recovering From a System Crash Your audit records will be preserved in the event of a system crash. If your system were to crash, it will, if possible, reboot automatically. When your system reboots it will come up in multi-user mode with auditing enabled. Auditing will continue as before the crash. If your system cannot automatically reboot, you will have to determine and correct the problem.
Maintain proper permissions on the /etc/passwd password le and the / tcb/files/auth/user initial /username protected password le Establish password aging Delete and nullify expired passwords, user IDs, and passwords of users no longer eligible to access the system Before Adding Users . . . To ensure the maximum security of your users' directories and les, you must perform the following before adding users to a trusted system.
Setting Up Password and Account Securities Policies You can set up password and account security policies using SAM: 1. Run SAM: sam The SAM main menu is displayed. 2. Highlight System Securities Policies. A new screen is displayed that lets you choose from the following options: Password format policies Password aging policies General user account policies Terminal securities policies Refer to the following sections for how to set up the speci c aspects of password and account security.
If you select more than one of the above options, users will get to choose which they prefer at login time. Note 5. If you toggle User Specifics on, you can select additional options: a. Use Restriction Rates b. Allow Null Passwords For trusted systems, you should not allow null passwords. This severely compromises system security. Note 6. Select OK. Setting Up Password Aging Policies HP-UX lets you select password aging options.
6. Specify the Password Expiration Time (in days). The expiration time of a password speci es a time after which a user must change the password. 7. Indicate the Password Warning Time (in days). This is when to start sending warning messages to the user that they will need to change their password soon. 8. Specify the Password Lifetime (in days). The lifetime speci es the time at which the account associated with that password is locked.
Boot Authentication When setting up a general user account, you must ensure that the user is not authorized to boot in single-user mode. This must be reserved for the system administrator. See \Setting Up General User Account Policies" for instructions. See the System Administration Task manual and the following man pages for more information: default (4), getprpwent (3), and prpwd (4). Note It is critical that boot authentication be set to root and that the system reboots in single-user mode.
Each of these les enforces the security policy previously de ned in this chapter. Every user has entries in both les and login looks at both entries to authenticate login requests. All passwords are encrypted immediately after entry and stored in /tcb/files/auth/user initial /username on a trusted system. The password eld in /etc/passwd is ignored. A user with an empty password is forced to set a password upon login on a trusted system.
letter of the user account name. For example, authentication pro le for user dgarcia is stored in the le /tcb/files/auth/d/dgarcia. The protected password le is an important part of a C2-level trusted system. Key security elements are stored in the protected password database and are accessible only to superusers. You need to set password entries using character mode SAM. Password data not set for a user uses the system defaults stored in the le /tcb/files/auth/system/default.
Number of days before expiration when warning will appear Whether or not the user can use the account without a password Whether passwords are user-generated or system-generated Whether triviality checks are performed on user-generated passwords Type of system-generated passwords Times when the user is permitted to log in Time stamp of last successful login Terminal ID (TTY) of last successful login Time stamp of last unsuccessful login Number of unsuccessful logins since the last successful login Maximum n
Password Aging You can enable or disable password aging for each user. When password aging is enabled, the system maintains the following for the password: Minimum Time|speci es the minimum time required between password changes. Expiration time|speci es a time after which a user must change the password at login. Warning time|speci es the time before expiration when a warning will be issued to the user.
Device Assignment Database The device access information is stored in the device assignment database, / tcb/files/auth/devassign, which contains an entry for each device on the trusted system.
Manipulating the Trusted System Databases Table 2-2 lists the library routines you can use to access information in the password les and other trusted system databases. Refer to the HP- UX Reference for details. Table 2-2.
Account and Terminal Lock Flags You can set or reset account or terminal lock ags using SAM. Refer to the sam (1M) man page or use SAM to set the ags. Changing the Owner of a File If you have superuser privilege, you can use the chown (8) to change the owner of a le. This can be a security problem because a user can cover his tracks or change owners of a le to acquire additional disk space on the system. Refer to the chown man page for additional information.
3 Practices that Enforce the Trustworthiness of the System The way an HP-UX trusted system is run determines how secure it will be. This chapter describes some of the practices that help to enforce and maintain C-level HP-UX system security. Background on Security Practices To run a secure system, you need to set up and run your system according to standard practices and be aware of potential threats. To do this you need a strong background in UNIX security basics.
This book is available from your local computer bookstore or by ordering ISBN 0-937175-72-2 from O'Reilly & Associates, Inc. at 1-800-889-8969 or via email at ORDER@ORA.COM. Additional detailed information that describes good security practices is provided in \Guidelines for Running a Trusted System" in Chapter 12 of HP-UX System Administration Tasks .
C-level protected subsystems In addition, on a trusted system, the system administrator is responsible for maintaining the Trusted Computing Base. For details about maintaining Unix systems and protecting against system threats, refer to Practical UNIX Security by S. Gar nkel and G. Spa ord.
For example, passwords should have the following characteristics: Six or more characters including asterisks and slashes Contain both alphabetic and numeric characters Contain both upper- and lowercase characters Be easy to remember Do not use a password that is easily associated with you, such as a pet name or a hobby Do not use a password found in a dictionary, even if it is spelled backwards. Software programs exist that can nd and match it.
Refer to the section \Eliminating Pseudo-Accounts and Protecting Key Subsystems" in Chapter 12 of HP-UX System Administration Tasks for information relevant to keeping accounts listed in /etc/passwd secure. Managing File and Directory Access Along with traditional HP-UX le access protection, les and directories can be protected from unauthorized access by using Access Control Lists (ACLs).
Specify site guidelines. Involve users and management in determining these guidelines. Ensure the physical security of systems and disks containing the audit logs, backups of these logs, and printouts of these logs. Provide a backup power source (UPS) for the disks containing the audit log so the data are not lost in the event of power failure. Provide disk mirroring and other high availability support for the audit log disks.
Privileged Groups A \privilege" is the ability to ignore access restrictions and change restrictions imposed by security policy and implemented in an access control mechanism. On HP-UX, only system administrators and members of certain groups are the only privileged users. The system administrator can associate a group with a system capability so that members of certain groups can be granted special privileges. The groups are called privileged groups .
Most system administration tasks should be performed by invoking SAM, because its menus restrict choices and thus reduces potential damage. If the root user forgets the root password, reboot the system in single-user state, and reassign the password. Superusers should construct at and cron jobs carefully. When at and cron are executed, the system searches the path set by root. Set your le creation mask with a umask of 077 before creating a le.
Practices that Compromise the 4 Trustworthiness of the System This chapter describes some of the practices that compromise the trustworthiness of your HP-UX trusted system. Basically, not following the good security practices and guidelines described in Chapter 3 of this manual and in Chapter 12 of HP-UX System Administration Tasks amounts to putting your system at risk. Lack of Password Security A user must log onto the system by specifying a user name and a password.
developing security policy and make them aware of the advantages for them and possible bad consequences they could face.
Lack of Routine System Checks Part of implementing system security is being good at interpreting events and recognizing questionable activities. A system administrator that doesn't perform routine system checks is putting the system at risk. Auditing Not Used Effectively You have the ability to enable auditing to record events of various types on the system.
Unsafe Storage of System Backups It doesn't matter how secure your system is if the backup tapes are stored where they can be accessed. A full system can be replicated from the backup tapes. Typically, full system backups are stored o site in a secure facility on a regular basis. Lack of Physical Security One of the most important, yet overlooked, aspects of computer system security is keeping the physical computer and related documentation in a safe area. This section summarizes the major risks.
Environmental Risks Not following speci ed site preparation guidelines when setting up your system enironment can leave it open to physical problems. For example, most computer systems work best in within certain temperature ranges where they are not exposed to water, smoke, re, dust, insects, open windows, food, or drink.
A Audit Record Format This appendix describes the format and structure of Hewlett-Packard's audit trail as shipped with HP-UX 10.10. Note that access to the auditing system is restricted to the system administrator. The commands to start auditing are located in the le /sbin/init.d/ auditing. The default values for the event types that are going to be audited, the sizes of the les, and le names are stored in /etc/ rc.config.d/auditing .
Real group ID E ective user ID E ective group ID System Call Audit Record Format System call records have a format that is understood by the kernel and are generated as a result of invoking system services. System call records are generated within the kernel. Each audit record consists of an audit record header and a record body . The record body is the variable-length part of an audit record containing more information about the audited activity.
The man pages for each of the system calls provide information about the type, count, and de nitions of each of the parameters for the system calls. The record body contains the parameters of the system calls that generated the audit record. Self-Auditing Audit Record Format Self-auditing processes are those which call audwrite (2). Self-auditing records contain the following: Date the date the event occurred. Time the time the audited event completed.
audevent (1m) audisp (1m) audsys (1m) audusr (1m) fbackup (1m) Text in the record structure includes information on the outcome of the command. For more information, see the audwrite (2) man page and the following section. Self-Auditing Commands The following sections describe the formats of the self-auditing commands. Review the Text eld to see the possible information that will be put into the audit trail as a result of executing the command.
chsh(1) Header Event User ID Real Group ID E ective Group ID Text EN CHSH \User=",username,\shell=", message \Permission denied" \Temporary le busy" \Can't create temporary le" \Can't recover" \Successfully changed" \Chsh failed" login(1) Header Event User ID Real Group ID E ective Group ID Text EN LOGINS \User=",username, \uid=", userid, \audid=", auditID, msg \attempted to login - too many users on the system" \attempted to login - not on system console" \attempted to login - must exec login from t
\attempted to login - bad audit ag" \attempted to login - bad audit id" \Successful login" \attempted to login - no shell" \Failed login (bailout)" \attempted to login - bad user id" \attempted to login - cannot execute /usr/bin/passwd" \attempted to login - failed login validate" newgrp(1) Header Event User ID Real Group ID E ective Group ID Text EN NEWGRP \newgrp=",group name,message \Sorry." \You have no shell." \Failed newgrp." \Successful newgrp.
Text \User=",username,message \Password successfully changed." \Attempt to change password failed.
audsys(1M) Header Event User ID Real Group ID E ective Group ID Text EN AUDSYS \audsys " \audsys -n" \audsys -f" \audsys -c", current audit le, \-s", current audit le switch size \audsys -x", next audit le, \-z", next audit le switch size \audsys -s", current audit le switch size \audsys -z", next audit le switch size \audsys: unable to open/lock /.secure" \audsys: unable to open/lock /.secure/etc/audnames" \audsys: unknown internal error" \audsys: could not nd /.
\audsys: auditing system unchanged." \audsys: auditing system unchanged." \audsys: unknown current audit le in use ", system current audit le, \audsys: unknown next audit le in use ", system next audit le, \audsys: auditing system unchanged" \audsys: current and next le set to same le (no-next)" \audsys: next audit le is changed to", next audit le \audsys: reset next le to NULL" \audsys: corrected /.
argument list of users, \will not be audited" fbackup(1M) Header Event User ID Real Group ID E ective Group ID Text EN SAMFBACKUP or EN SAMIBACKUP \Perform a Full Backup Online" \Perform an Incremental Backup Online" A-10 Audit Record Format
B Commands and System Calls This appendix lists commands and system calls that are part of a C2-level HPUX trusted system. For more information, refer to the online man pages. Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
Table B-1.
C SFUG Supplement Security Features User's Guide Supplement August 1996 5965-4311 Welcome to the world of HP-UX, a powerful, versatile system that meets the computing needs of diverse groups of users. You can use HP-UX simply to run applications, or you can develop your own applications in its rich software development environment. Trusted System ============== Your HP-UX system can be con gured as a C2-level trusted system, as described in Section 2.
HP-UX provides additional security features such as discretionary access control and system auditing. Security Policy =============== A \security policy" is a statement of the rules and practices that regulate how an organization manages, protects, and distributes sensitive information. HP-UX C2-level security expands on existing HP-UX security mechanisms and provides procedures and guidelines to help enforce your company's security policy.
When you log in to the system, you may see a message informing you that your password is about to expire. In this case, you must change your password by using the passwd command as follows: $passwd The system prompts you for your old password. When you type it successfully, you are prompted for a new password which you must type then retype to validate it.
For user-generated passwords, when you choose a password, you need to follow certain guidelines for selection. For example, when you change your password, pick a new password and do not reuse an old one.
system, if required, by using sam(1m) and system calls such as setuid(2) and setgid(2). You can be a member of more than one group, and you can change your current group with the newgrp(1) command. Errors may occur if you attempt to change to a group that doesn't exist or to a group to which you do not have access. See the newgrp(1), setuid(2), and setgid(2) online man pages for more information.
Using discretionary access control (DAC), owners of objects containing data can allow or deny access to these objects at their own discretion, on a need-to-know basis. Objects are things such as les, devices, or interprocess communications mechanisms that another user's process or your process is attempting to access. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission to any other subject.
An access control list is a set of user, group, and mode entries associated with a le that specify permissions for all possible user ID or group ID combinations. Refer to the acl(5) online man page for detailed information about access control lists and de nitions of related security terminology. Listing ACLs |||||| To see who can access certain les and directories and what permissions are allowed, you can use the lsacl command: $ lsacl lename The system responds with a listing in this general form: (user.
By adding entries to access control lists, you can allow or deny access to particular users or groups of users. You can set or change ACLs using the chacl command. The general form of the chacl command is as follows: $ chacl 'user.group operator mode' lename where: user is the login name; a % here means all users. group is the user's group; a % here means all groups. operator is +, -, or = to add, deny, or specify permissions to existing ACL entries.
* Only the fbackup (1M) and frecover(1M) le archive utilities handle ACLs correctly. Archive programs such as AR(1), cpio(1), ftio(1), tar(1), and dump(1M) are unable to handle ACLs on les with optional ACL entries. Backing Up and Recovering Files =============================== On a trusted system, you should only use fbackup(1M) and frecover(1M) to back up and recover les selectively. These commands retain ACLs that have been applied to the les.
at runs commands in your home directory at the time you specify. crontab runs commands in your home directory at regularly speci ed intervals. Prerequisites for using at and crontab ||||||||||||||||||| Before you can use crontab or at, your system administrator must set up certain les that allow you permission to run these commands. Two les called at.allow and at.deny in /usr/lib/cron determine whether you can use the at command. You can use it if your name is in at.allow. If at.
at -l You will see output such as: job 617 at wed apr 10 030:30:00 1996 Running Commands at Regular Intervals using crontab |||||||||||||||||||||||||You can use the crontab command to run commands at regular intervals. For example, you can send a weekly reminder for a meeting to your mailbox or erase all tmp les everyday. The crontab command creates a le called by your username in the directory /usr/spool/cron/crontabs. The commands in the le are executed at the speci ed intervals in your home directory.
eld indicates the hour (8). The asterisks mean all legal values. The 4 means Thursday. At midnight everyday, crontab erases les with a *.tmp extension in your directory. Error messages are redirected to a le called errmsg in your home directory. Refer to the crontab(1) man page for more information. Submitting Batch Jobs ||||||||||You can also use the batch command to submit a batch le. For example: batch nro lename > out le Ctrl-D This command executes an nro command when the system is able to handle it.
Index A D Access Control Lists (ACLs), 1-5, 1-8 account lock ags, 2-35 accounts policies, 2-27 aging, password, 2-26 analyzing audit les, 2-20 auditing, 1-10, 2-10 administering, 2-11 administration guidelines, 3-5 audit le analysis, 2-20 audit records, 2-19 commands, 2-11 default parameters, 2-14 event types and system calls, 2-15 log les, 2-18 maintaining, 2-21 selecting audit data, 2-17 setting up, 2-11 turning on, 2-12 audit trail, 2-10 audomon, 2-19 authentication, 1-9 daemon, auditing, 2-19 device
monitor daemon, 2-19 N National Computer Security Center (NCSC), 1-6 O object, 1-3, 1-8 P password aging policies, 2-26 controls, 2-23, 2-26 empty, 2-29 les, 2-28 format policies, 2-25 password aging, 2-32 protected password database, 2-30 selecting, 2-31 setting up policies, 2-25 user-generated, 2-31 patches, 2-4 Practical UNIX Security, 1-11 protected password database, 2-30, 2-32 S .
