HP-UX System Administrator's Guide: Security Management
HP-UX 11i Version 3
HP Part Number: B3921-90059
Published: September 2011
Edition: 7
© Copyright 2011 Hewlett-Packard Development Company L.P
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 document, including, but not limited to, the implied warranties
of merchantability and fitness 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 A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained
from your local Sales and Service Office.
U.S. Government License Proprietary computer software. Valid license from HP required for possession, use or copying. Consistent
with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for
Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.
Trademark Notices UNIX® is a registered trademark in the United States and other countries, licensed exclusively through The
Open Group. VERITAS® is a registered trademark of Symantec Corporation.
Acknowledgments This product includes software developed by the Apache Software Foundation. This documentation is based
on information from the Apache Software Foundation (http://www.apache.org).
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org).
Table of Contents
About this Document.................................................................................................................15
I Protecting Systems...................................................................................................................21
1 Installing the HP-UX Operating Environment Securely.............................................................23
1.1 Installation Security Considerations..................................................................23
1.2 Preventing Security Breaches During the Boot Process........................................23
1.3 Enable Login Security for root........................................................................24
1.4 Using Boot Authentication to Prevent Unauthorized Access.................................25
1.5 Setting Install-Time Security Options................................................................25
1.6 Installing Security Patches..............................................................................26
1.7 Postinstallation Security Tips for Backup and Recovery.......................................26
2 Administering User and System Security..............................................................................29
2.1 Managing User Access.................................................................................29
2.1.1 Monitoring User Accounts.......................................................................29
2.1.2 Monitoring Guest Accounts.....................................................................30
2.1.3 Creating Application User Accounts.........................................................30
2.1.4 Managing Group Accounts....................................................................31
2.2 Authenticating Users During Login..................................................................31
2.2.1 Explanation of the Login Process.............................................................32
2.2.2 Checking the login Tracking Files (btmp and wtmp)...................................33
2.2.2.1 Last Command Examples................................................................33
2.2.3 Checking Who Is Logged In...................................................................34
2.3 Authenticating Users with PAM.......................................................................34
2.3.1 Overview.............................................................................................34
2.3.2 PAM Libraries.......................................................................................36
2.3.3 Systemwide Configuration Using /etc/pam.conf.......................................37
2.3.4 Sample /etc/pam.conf File....................................................................38
2.3.5 The /etc/pam_user.conf User Configuration File.......................................39
2.3.6 Examples: How PAM Works for Login.....................................................39
2.4 Managing Passwords...................................................................................41
2.4.1 System Administrator Responsibilities.......................................................41
2.4.2 User Responsibilities.............................................................................41
2.4.3 Criteria of a Good Password..................................................................42
2.4.4 Changing the /etc/passwd Password File................................................42
2.4.4.1 Examples of passwd Commands.....................................................42
2.4.4.2 The /etc/passwd File Format..........................................................43
2.4.5 The /etc/shadow Shadow Password File.................................................43
Table of Contents 3
2.4.6 Eliminating Pseudo-Accounts and Protecting Key Subsystems in
/etc/passwd................................................................................................45
2.4.7 Secure Login with HP-UX Secure Shell.....................................................46
2.4.8 Securing Passwords Stored in NIS...........................................................46
2.4.9 Securing Passwords Stored in LDAP Directory Server.................................46
2.5 Defining System Security Attributes.................................................................46
2.5.1 Configuring Systemwide Attributes...........................................................48
2.5.2 Configuring Per-User Attributes...............................................................48
2.5.2.1 Examples of Defining User-Specific Attributes with userdbset................49
2.5.2.2 INACTIVITY_MAXDAYS and the Shadow Password File......................49
2.5.3 Troubleshooting the User Database.........................................................49
2.6 Handling setuid and setgid Programs.............................................................50
2.6.1 Why setuid and setgid Programs Can Be Risky.........................................51
2.6.2 How IDs Are Set..................................................................................51
2.6.3 Guidelines for Limiting Setuid Power.......................................................51
2.7 Preventing Stack Buffer Overflow Attacks.........................................................52
2.8 Protecting Unattended Terminals and Workstations...........................................53
2.8.1 Controlling Access Using /etc/inittab and Run Levels................................53
2.8.2 Protecting Terminal Device Files..............................................................54
2.8.3 Configuring the Screen Lock...................................................................54
2.8.3.1 Configuring the TMOUT Variable....................................................54
2.8.3.2 Configuring the CDE Lock Manager................................................55
2.9 Protecting Against System Access by Remote Devices........................................55
2.9.1 Controlling Access Using /etc/dialups and /etc/d_passwd........................56
2.10 Securing Login Banners...............................................................................57
2.11 Protecting the root Account...........................................................................58
2.11.1 Monitoring root Account Access.............................................................58
2.11.2 Using the Restricted SMH Builder for Limited Superuser Access...................58
2.11.3 Reviewing Superuser Access..................................................................59
3 HP-UX Standard Mode Security Extensions...........................................................................61
3.1 Overview....................................................................................................61
3.2 Security Attributes and the User Database.......................................................62
3.2.1 System Security Attributes.......................................................................62
3.2.2 Configuring Systemwide Attributes..........................................................62
3.2.3 User Database Components...................................................................63
3.2.3.1 Configuration Files.........................................................................63
3.2.3.2 Commands..................................................................................63
3.2.3.3 Attributes.....................................................................................63
3.2.3.4 Manpages...................................................................................64
3.2.4 Configuring Attributes in the User Database.............................................65
3.2.5 Troubleshooting the User Database.........................................................65
4 Table of Contents
4 Remote Access Security Administration................................................................................67
4.1 Overview of Internet Services and Remote Access Services.................................67
4.1.1 Securing ftp..........................................................................................68
4.1.2 Securing Anonymous ftp.........................................................................69
4.1.3 Denying Access Using /etc/ftpd/ftpusers.................................................69
4.1.4 Other Security Solutions for Spoofing.......................................................70
4.2 The inetd Daemon.......................................................................................70
4.2.1 Securing inetd......................................................................................71
4.2.1.1 Denying or Allowing Access Using /var/adm/inetd.sec......................72
4.3 Protection Against Spoofing with TCP Wrappers..............................................72
4.3.1 Additional Features of TCP Wrappers......................................................73
4.3.2 TCP Wrappers Do Not Work with RPC Services.......................................73
4.4 Secure Internet Services................................................................................73
4.5 Controlling an Administrative Domain.............................................................74
4.5.1 Verifying Permission Settings on Network Control Files...............................75
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH)................................76
4.6.1 Key Security Features of HP-UX Secure Shell.............................................76
4.6.2 Software Components of HP-UX Secure Shell...........................................77
4.6.3 Running HP-UX Secure Shell...................................................................78
4.6.3.1 Running the ssh Client....................................................................78
4.6.3.2 Running the sftp Client...................................................................79
4.6.3.3 Running the scp Client...................................................................79
4.6.4 HP-UX Secure Shell Privilege Separation..................................................79
4.6.5 HP-UX Secure Shell Authentication..........................................................80
4.6.5.1 GSS-API.......................................................................................80
4.6.5.2 Public Key Authentication...............................................................81
4.6.5.3 Host-Based and Public Key Authentication........................................81
4.6.5.4 Password Authentication................................................................81
4.6.6 Communication Protocols......................................................................82
4.6.7 HP-UX Secure Shell and the HP-UX System...............................................82
4.6.8 Associated Technologies.......................................................................83
4.6.9 Strong Random Number Generator Requirement......................................83
4.6.10 TCP Wrappers Support........................................................................83
4.6.11 chroot Directory Jail.............................................................................84
II Protecting Data......................................................................................................................85
5 File System Security..........................................................................................................87
5.1 Controlling File Access..................................................................................87
5.1.1 Setting File Access Permissions.................................................................88
5.1.2 Setting File Ownership...........................................................................89
5.1.3 Protecting Directories.............................................................................89
5.1.4 Protecting Files Related to User Accounts..................................................90
Table of Contents 5
5.1.5 Locating and Correcting File Corruption Using fsck....................................90
5.2 Setting Access Control Lists............................................................................91
5.3 Using HFS ACLs...........................................................................................91
5.3.1 HFS ACLs and HP-UX Commands and Calls.............................................93
5.4 Using JFS ACLs............................................................................................95
5.4.1 Definition of a JFS ACL..........................................................................95
5.4.2 How the System Generates a JFS ACL.....................................................95
5.4.3 Minimal JFS ACL..................................................................................96
5.4.4 Additional JFS ACL user and group Entries...............................................96
5.4.5 JFS ACL group and class Entries.............................................................96
5.4.6 Using the setacl and getacl Commands...................................................97
5.4.7 Effect of chmod on class Entries..............................................................97
5.4.8 Example of Changing a Minimal JFS ACL................................................98
5.4.9 Default JFS ACLs..................................................................................99
5.4.10 Changing JFS ACL with the setacl Command........................................100
5.4.10.1 Using the Modify and Delete Options...........................................100
5.4.10.2 Using the -f Option....................................................................100
5.4.10.3 Effective Permissions and setacl -n................................................101
5.5 Comparison of JFS and HFS ACLs................................................................102
5.5.1 JFS and HFS Command and Function Mapping.......................................102
5.6 ACLs and NFS...........................................................................................103
5.7 Security Considerations for /dev Device Special Files.....................................103
5.8 Protecting Disk Partitions and Logical Volumes...............................................104
5.9 Security Guidelines for Mounting and Unmounting File Systems........................104
5.10 Controlling File Security on a Network.........................................................106
5.10.1 Check Permission Settings on Network Control Files................................106
5.10.2 Files Mounted in an NFS Environment..................................................106
5.10.2.1 Server Vulnerability....................................................................107
5.10.2.2 Client Vulnerability.....................................................................107
5.10.2.3 How to Safeguard NFS-Mounted Files..........................................107
6 Compartments...............................................................................................................109
6.1 Overview..................................................................................................109
6.1.1 Compartment Architecture.....................................................................109
6.1.2 Default Compartment Configuration.......................................................111
6.2 Planning the Compartment Structure.............................................................111
6.3 Compartment Components..........................................................................112
6.3.1 Compartment Configuration Files..........................................................112
6.3.2 Compartment Commands....................................................................112
6.3.3 Compartment Manpages.....................................................................113
6.4 Compartment Rules and Syntax...................................................................114
6.4.1 Compartment Definition.......................................................................114
6.4.2 File System Rules................................................................................116
6 Table of Contents
6.4.3 IPC Rules...........................................................................................117
6.4.4 Network Rules...................................................................................119
6.4.5 Miscellaneous Rules............................................................................122
6.4.6 Example Rules File..............................................................................123
6.5 Configuring Compartments.........................................................................124
6.5.1 Activating Compartments.....................................................................124
6.5.2 Defining a Compartment Configuration.................................................124
6.5.2.1 Changing Compartment Rules.......................................................125
6.5.2.2 Changing Compartment Names...................................................125
6.5.3 Running an Application in a Compartment............................................125
6.5.4 Login Directly to a Compartment..........................................................126
6.6 Troubleshooting Compartments....................................................................126
6.7 Using Discover Mode to Generate Initial Compartment Configuration...............127
6.8 Compartments in HP Serviceguard Clusters...................................................128
7 Fine-Grained Privileges...................................................................................................131
7.1 Overview...................................................................................................131
7.2 Fine-Grained Privileges Components.............................................................131
7.2.1 Commands.........................................................................................131
7.2.2 Manpages.........................................................................................132
7.3 Available Privileges....................................................................................132
7.3.1 Compatibility Information for Divided Privileges.......................................135
7.4 Configuring Applications with Fine-Grained Privileges.....................................136
7.4.1 Privilege Model...................................................................................138
7.4.2 Compound Privileges..........................................................................138
7.5 Security Implications of Fine-Grained Privileges..............................................139
7.5.1 Privilege Escalation..............................................................................139
7.6 Fine-Grained Privileges in HP Serviceguard Clusters........................................139
7.7 Troubleshooting Fine-Grained Privileges........................................................140
III Protecting Identity................................................................................................................141
8 HP-UX Role-Based Access Control.....................................................................................143
8.1 Overview..................................................................................................143
8.2 Access Control Basics.................................................................................144
8.2.1 Simplifying Access Control with Roles....................................................145
8.3 HP-UX RBAC Components...........................................................................146
8.3.1 HP-UX RBAC Access Control Policy Switch..............................................147
8.3.2 HP-UX RBAC Configuration Files...........................................................147
8.3.3 HP-UX RBAC Commands.....................................................................148
8.3.4 HP-UX RBAC Manpages......................................................................148
8.3.5 HP-UX RBAC Architecture.....................................................................149
8.3.6 HP-UX RBAC Example Usage and Operation.........................................150
Table of Contents 7
8.4 Planning the HP-UX RBAC Deployment..........................................................151
8.4.1 Planning the Roles..............................................................................152
8.4.2 Planning Authorizations for the Roles....................................................152
8.4.3 Planning Command Mappings.............................................................153
8.4.4 HP-UX RBAC Limitations and Restrictions................................................153
8.5 Configuring HP-UX RBAC............................................................................154
8.5.1 Configuring Roles...............................................................................155
8.5.1.1 Creating Roles.............................................................................155
8.5.1.2 Assigning Roles to Users...............................................................156
8.5.1.3 Assigning Roles to Groups............................................................157
8.5.2 Configuring Authorizations..................................................................157
8.5.3 Configuring Additional Command Authorizations and Privileges...............158
8.5.4 Configuring HP-UX RBAC with Fine-Grained Privileges.............................160
8.5.5 Configuring HP-UX RBAC with Compartments.........................................162
8.6 Using HP-UX RBAC....................................................................................163
8.6.1 Using the privrun Command to Run Applications with Privileges................163
8.6.1.1 HP-UX RBAC in Serviceguard Clusters.............................................165
8.6.2 Using the privedit Command to Edit Files Under Access Control................165
8.6.3 Customizing privrun and privedit Using the ACPS...................................166
8.6.4 Generating Keystroke and Command Logs............................................167
8.6.4.1 Keystroke Logging.......................................................................167
8.6.4.2 Alternate Logging.......................................................................168
8.7 Troubleshooting HP-UX RBAC.......................................................................168
8.7.1 The rbacdbchk Database Syntax Tool....................................................168
8.7.2 privrun -v Information..........................................................................169
9 Audit Administration.......................................................................................................171
9.1 Auditing Components..................................................................................172
9.1.1 Commands.........................................................................................172
9.1.2 Audit Configuration Files......................................................................172
9.1.3 Audit Manpages.................................................................................173
9.2 Auditing Your System..................................................................................173
9.2.1 Planning the Auditing Implementation....................................................173
9.2.2 Enabling Auditing...............................................................................174
9.2.3 Disabling Auditing..............................................................................175
9.2.4 Monitoring Audit Files.........................................................................175
9.2.5 Performance Considerations.................................................................176
9.2.6 Guidelines for Administering the Auditing System...................................176
9.3 Auditing Users...........................................................................................176
9.4 Auditing Events..........................................................................................177
9.5 Audit Trails................................................................................................179
9.5.1 Configuring Audit Trails.......................................................................180
9.5.2 Monitoring and Managing Audit Trails..................................................181
8 Table of Contents
9.6 Using the Audit Filtering Tools......................................................................182
9.7 Using filter.conf .........................................................................................183
9.8 Using the Audit Reporting Tools...................................................................183
9.8.1 Examples of Using the auditdp Command..............................................185
9.9 Viewing Audit Logs.....................................................................................186
9.9.1 Examples of Using the audisp Command................................................187
9.10 Self-Auditing.............................................................................................187
9.11 HP-UX RBAC Auditing................................................................................188
9.11.1 Auditing Based on HP-UX RBAC Criteria and the /etc/rbac/aud_filter
File...........................................................................................................188
9.11.2 Procedure for Auditing HP-UX RBAC Criteria..........................................189
A Trusted Systems...................................................................................................................191
A.1 Setting Up a Trusted System.............................................................................191
A.2 Auditing a Trusted System................................................................................192
A.3 Managing Trusted Passwords and System Access................................................192
A.3.1 Password Files.........................................................................................193
A.3.1.1 The /etc/passwd File........................................................................193
A.3.1.2 The /tcb/files/auth/ Database..........................................................194
A.3.2 Password Selection and Generation..........................................................195
A.3.3 Password Aging......................................................................................195
A.3.4 Password History and Password Reuse.......................................................196
A.3.5 Time-Based Access Control......................................................................196
A.3.6 Device-Based Access Control....................................................................196
A.3.7 Manipulating the Trusted System Databases...............................................197
A.4 Guidelines for Trusted Backup and Recovery......................................................197
B Other Security Products........................................................................................................199
B.1 Protecting Systems...........................................................................................199
B.1.1 HP-UX Bastille...........................................................................................199
B.1.2 HP-UX HIDS.............................................................................................199
B.1.3 HP-UX IPFilter...........................................................................................200
B.1.4 Security Patches.......................................................................................200
B.2 Protecting Data...............................................................................................200
B.2.1 HP-UX Containers (SRP)............................................................................200
B.2.2 HP-UX Encrypted Volume and File System (EVFS).........................................201
B.2.3 HP-UX IPSec............................................................................................201
B.2.4 HP-UX OpenSSL .....................................................................................201
B.2.5 HP-UX Secure Shell .................................................................................202
B.2.6 HP-UX Trusted Computing Services.............................................................202
B.2.7 HP-UX Whitelisting .................................................................................203
B.3 Protecting Identity...........................................................................................203
B.3.1 HP-UX AAA Server (RADIUS).....................................................................203
Table of Contents 9
B.3.2 HP-UX Directory Server............................................................................204
B.3.3 HP-UX LDAP-UX Integration.......................................................................204
Glossary...............................................................................................................................205
Index....................................................................................................................................213
10 Table of Contents
List of Figures
2-1 HP-UX Authentication Modules Under PAM..........................................................35
5-1 File and Directory Permission Fields....................................................................88
6-1 Compartment Architecture...............................................................................110
8-1 HP-UX RBAC Architecture................................................................................150
8-2 Example Operation After Invoking privrun.........................................................151
11
List of Tables
3-1 User Database Configuration Files.....................................................................63
3-2 User Database Commands................................................................................63
3-3 User Attributes.................................................................................................64
3-4 User Database Manpages................................................................................64
4-1 Internet Services Components and Access Verification, Authorization, and
Authentication.................................................................................................67
4-2 Software Components of HP-UX Secure Shell.......................................................77
5-1 Differences Between File and Directory Privileges.................................................88
5-2 HFS ACL Commands........................................................................................94
5-3 HFS ACL System Calls......................................................................................94
5-4 Commands and Calls Affecting ACL Entries.........................................................94
5-5 HFS and JFS ACL Equivalents...........................................................................102
6-1 Compartment Configuration Files.....................................................................112
6-2 Compartment Commands...............................................................................113
6-3 Compartment Manpages................................................................................113
7-1 Fine-Grained Privileges Commands..................................................................132
7-2 Fine-Grained Privileges Manpages...................................................................132
7-3 Available Privileges........................................................................................132
8-1 Example of Authorizations Per User..................................................................144
8-2 Example of Authorizations Per Role...................................................................145
8-3 HP-UX RBAC Configuration Files.......................................................................147
8-4 HP-UX RBAC Commands.................................................................................148
8-5 HP-UX RBAC Manpages.................................................................................148
8-6 Example Planning Results................................................................................155
9-1 Audit Commands...........................................................................................172
9-2 Audit Configuration Files.................................................................................172
9-3 Audit Manpages............................................................................................173
9-4 audevent Command Options...........................................................................178
12 List of Tables
List of Examples
2-1 Pseudo- and Special System Accounts.................................................................45
5-1 Creating an HFS ACL.......................................................................................93
5-2 Multiple HFS ACL Matches................................................................................93
13
14
About this Document
Publication History
The document publication date and part number indicate its current edition. The
publication date will change when a new edition is released.
To ensure that you receive the new editions, you should subscribe to the appropriate
product support service. Contact your HP sales representative for details.
You can find the various versions of this document at:
http://www.hp.com/go/hpux-core-docs
Click HP-UX 11i v3.
September 2011 Part Number B3921–90059
• Updated the Compartment chapter (see Chapter 6).
• Updated the Fine-Grained Privileges chapter (see Chapter 7.
• Reorganized Appendix B in three parts: Protecting Systems,
September 2010 Part Number B3921-90020
• Removed the Bastille chapter since the Bastille product now
• Added the HP-UX Directory Server product in Appendix B
• Added the HP-UX LDAP product in Appendix B (page 199).
• Updated all links to docs.hp.com to the Business Support
Protecting Data, and Protecting Identity and added the HP-UX
OpenSSL and HP-UX Whitelisting security products (see
Appendix B).
has its own user guide. Added the Bastille product in
Appendix B (page 199).
(page 199).
Center. The HP-UX documentation is now located at the
Business Support Center. For the HP-UX security collection,
see http://www.hp.com/go/hpux-security-docs.
September 2009 Part Number 5992–6416
• Added the HP-UX PAM RADIUS module to the PAM Libraries
section (see Section 2.3.2).
• Added a new section in the Bastille chapter, Selecting
Install-Time Security.
This section used to be documented in the HP-UX 11i v3
Installation and Update Guide.
• Updated the Compartment chapter (see Chapter 6).
15
• Updated the HP-UX Role-Based Access Control chapter (see
Chapter 8 ).
• Updated the Audit Administration chapter (see Chapter 9).
• Added security products to Appendix B (see Appendix B).
March 2008 Part Number 5992–3387
• Divided the document into three parts: Protecting Systems,
Protecting Data, and Protecting Identity.
• Added a chapter to document HP-UX Standard Mode
Security Extensions (see Chapter 3).
• Replaced Security Patch Check with Software Assistant.
• Added a figure to show the HP-UX Bastille user interface.
• Added the HP-UX Bastille configuration log file
assessment-log.config.
• Made various edits.
October 2007 Part Number 5992-2395
• Added a chapter to describe HP-UX Bastille.
August 2007 Part Number 5992-1933
• Removed Process Resource Manager (PRM) from the product
list that does not support shadow passwords (see
Section 2.4.5).
• Corrected search to nsearch in permission_list (see
Section 6.4.2).
16
February 2007 Part Number 5991-6482
First Edition
NOTE: The volumes in the HP-UX System Administrator’s Guide can be updated
independently. Therefore, the latest versions of the volumes in the set can vary with time
and with respect to each other. The latest versions of each volume are available at:
http://www.hp.com/go/hpux-core-docs
Click HP-UX 11i v3.
Intended Audience
The HP-UX System Administrator’s Guide is written for administrators of HP-UX systems
of all skill levels needing to administer HP-UX systems beginning with Release HP-UX 11i
version 3.
While many topics in this set apply to previous releases, much has changed in HP-UX
11i version 3; therefore, for information about prior releases, see Managing Systems
and Workgroups, a Guide for System Administrators.
About This Document Set
The HP-UX System Administrator’s Guide documents the core set of tasks (and associated
concepts) necessary to administer systems running HP-UX 11i Version 3. It is comprised
of the following volumes:
Overview Provides a high-level view of HP-UX 11i, its
components, and how they relate to each other.
Configuration Management Describes many of the tasks that you must perform
to configure and customize system settings and
the behavior of subsystems.
Logical Volume Management Documents how to configure physical volumes,
volume groups, and logical volumes using the HP
Logical Volume Manager (LVM).
Security Management Documents the data and system security features
of HP-UX 11i.
Routine Management Tasks Documents many of the ongoing tasks you must
perform to keep your system running smoothly.
HP-UX System Administrator's Guide: Security Management is divided into three parts:
Protecting Systems, Protecting Data, and Protecting Identity. These parts include the
following topics:
Chapter 1 Describes security considerations related to the boot and installation
process.
Chapter 2 Describes how to administer user and system security after the operating
system is installed.
Chapter 3 Describes the features and components of HP-UX Standard Mode
Security Extentions.
Chapter 4 Describes how to secure remote access to your system.
Chapter 5 Describes how to control and protect file systems.
Chapter 6 Describes compartments and how to isolate components of a system
from one another.
Chapter 7 Describes fine-grained privileges and how to divide the powers of
superusers into a set of privileges.
Chapter 8 Describes the features and components of HP-UX Role-Based Access
Control.
Chapter 9 Describes the administration of the audit system.
Appendix A Describes trusted systems.
Appendix B Describes other security products.
17
HP-UX 11i Release Names and Release Identifiers
With HP-UX 11i, HP delivers a highly available, secure, and manageable operating
system. HP-UX 11i supports enterprise, mission-critical, and technical computing
environments and is available on both HP 9000 systems and HP Integrity servers.
Each HP-UX 11i release has an associated release name and release identifier. The
uname command with the -r option returns the release identifier. See the following table
for a list of releases available for HP-UX 11i:
Supported Processor ArchitectureRelease NameRelease Identifier
HP 9000HP-UX 11i version 1B.11.11
B.11.23
HP-UX 11i version 2B.11.23
HP-UX 11i version 2, September
2004
HP-UX 11i version 3B.11.31
Intel™ Itanium™
HP 9000
Itanium
HP 9000
Itanium
For information on supported systems and processor architecture for various versions of
HP-UX 11i, see the HP-UX 11i system release notes specific to the version of HP-UX you
are running (for example, the HP-UX 11i Version 3 Release Notes).
18
Finding HP-UX Information
The following table outlines where to find general system administration information for
HP-UX. However, it does not include information for specific products.
Located atRefer ToIf you need to
Find out:
• What has changed in HP-UX
releases
• The contents of the Operating
Environments
• Firmware requirements and
supported systems for a
specific release
Install or update HP-UX
Administer an HP-UX system
The HP-UX 11i Release Notes
specific to your version of HP-UX.
For example, you may want to see
the HP-UX 11i Version 3 Release
Notes.
• Read Before Installing or
Updating to HP-UX
• HP-UX 11i Installation and
Update Guide
NOTE: See the documents for
your specific version of HP-UX.
Releases beginning with HP-UX
11i Version 3:
• HP-UX System Administrator’s
Guide (a multivolume set)
Other sources of system
administration information:
• nPartition Admnistrator's Guide
• Planning Superdome
Configurations (white paper)
• HP Instant Information media
• http://www.hp.com/go/
hpux-core-docs
Click HP-UX 11i v3.
• /usr/share/doc/ directory
The /usr/share/doc
directory contains only the
original release note for your
version of HP-UX. For revised
release notes, see your latest HP
Instant Information media or the
Business Support Center:
http://www.hp.com/go/
hpux-core-docs
Click HP-UX 11i v3.
• Media Kit (supplied with the
Operating Environment)
• HP Instant Information media
• http://www.hp.com/go/
hpux-core-docs
Click HP-UX 11i v3.
• HP Instant Information CD-ROM
• http://www.hp.com/go/
hpux-core-docs
Click HP-UX 11i v3.
• Planning Superdome
Configurations (white paper)
Related Information
Additional information about Security and HP-UX can be found at www.hp.com/go/
hpux-security-docs.
In particular, the following documents are available:
19
• HP-UX AAA Server Administrator's Guide
• HP-UX Host Intrusion Detection System Administrator's Guide
• HP-UX IPFilter Administrator's Guide
• HP-UX IPSec Administrator's Guide
• HP-UX Secure Shell Release Notes
Conventions
This document uses the following typographical conventions.
reboot(1M) An HP-UX manpage. reboot is the name and 1M is the section in the
HP-UX Reference. On the Web and on the Instant Information media,
it may be a hot link to the manpage itself. From the HP-UX command
line, you can enter “man reboot” or “man 1M reboot” to view the
manpage. See man(1) for more information.
Book Title The title of a book. On the web and on the Instant Information media,
it may be a hot link to the book itself.
KeyCap The name of a keyboard key. Return and Enter both refer to the same
key.
Emphasis Text that is emphasized.
Emphasis Text that is strongly emphasized.
Term The introduction of an important word or phrase.
ComputerOut Text displayed by the computer.
20
UserInput Commands and other text that you type.
Command A command name or qualified command phrase.
Variable The name of a variable that you may replace in a command or function
or information in a display that represents several possible values.
[ ] The contents are optional in formats and command descriptions.
{ } The contents are required in formats and command descriptions. If the
contents are a list separated by |, you must choose one of the items
. . . The preceding element may be repeated an arbitrary number of times.
| Separates items in a list of choices.
Part I Protecting Systems
One critical factor in enterprise security is system minimization and hardening. HP-UX 11i offers
a set of security features designed to address known and unknown vulnerabilities by running
only the services that are needed, thus minimizing a potential point of attack.
This section discusses the following HP-UX tools that protect a system against an attack, and
detect and react to threats:
• Installing the HP-UX operating environment securely (Chapter 1)
• Administering user and system security (Chapter 2)
• Standard Mode Security Extensions (Chapter 3)
• Remote access security administration (Chapter 4)
21
22
1 Installing the HP-UX Operating Environment Securely
This chapter describes security considerations related to the boot and installation
processes, including the following topics:
• Installation security considerations (Section 1.1)
• Preventing security breaches during the boot process (Section 1.2)
• Enable login security for root (Section 1.3)
• Using boot authentication to prevent unauthorized access (Section 1.4)
• Setting Install-Time Security options (Section 1.5)
• Installing security patches (Section 1.6)
• Postinstallation security tips for backup and recovery (Section 1.7)
1.1 Installation Security Considerations
Before you install or update to a new operating system or new software, make a practice
of addressing security considerations. Make the following security measures part of your
preparation for installation:
• Review the contents of your media kit. Read the Release Notes and other related
information at the Business Support Center:
http://www.hp.com/go/hpux-core-docs
Click HP-UX 11i v3.
• Decide which software you need and which you do not need. Do not install
unnecessary software. Consult other chapters of this document for help deciding on
security software products.
• Disconnect or disengage your system from the network, especially from a public
network, until your security modifications are complete. Consider what, if any,
security level you would like to deploy with. See Section 1.5 for more information.
• Make sure the system console is physically protected and your LAN console is either
disconnected, or used only through a network where clear-text-protocols like telnet
are allowed/protected. This is an important security consideration. Restricting access
to the system console helps prevent unauthorized persons from changing the security
settings of your system.
• Install the latest patches, especially security patches. See Section 1.6 for more
information.
• Maintain a backup and recovery system. See Section 1.7 for more information.
1.2 Preventing Security Breaches During the Boot Process
Security breaches can occur during the boot sequence. The boot process can be
interrupted, allowing an unauthorized person to access the system. If certain system files
1.1 Installation Security Considerations 23
are altered incorrectly or maliciously before the reboot, the system can have problems
during and after the reboot. Therefore, perform these preventative tasks:
• Make sure the system and system console are physically secure and that only
authorized users have access.
• Enable the boot authentication feature to allow only specified users to boot the
system to single user mode. See Section 1.4.
• Make sure system files are write protected; some might need to be read protected.
Following is a summary of the boot sequence that occurs when you turn on or reset the
computer. See HP-UX System Administrator's Guide: Routine Management Tasks for more
information on the boot sequence.
1. During booting, there is about a 10-second wait that allows you to override the
automatic boot sequence. At this point, an intruder can interrupt the boot sequence
and enter the system.
You can gain root access when you interrupt the boot sequence by pressing any
key. The ISL prompts you for a command. Entering the following command causes
the system to be in single-user mode:
ISL> hpux -is
If you are not using boot authentication, a user can then log in as root with no
password.
Boot authentication allows only specified users to log in as root.
2. If the boot sequence is not interrupted, the initialization process continues.
3. HP-UX goes through its initialization process and begins normal operation, ready
for login. At this point another security breach can occur if an intruder has already
gained root access.
If an intruder interrupts the boot process, they have gained root access to the system and
theoretically own the system. This ownership allows them to make changes to the system
through a great number of mechanisms.
1.3 Enable Login Security for root
Many network protocols such as rlogind and telnetd do not encrypt network
communication, making it easy for an intruder to sniff the administrative passwords from
the network. Try to minimize the usage of these nonsecure protocols.
To prevent an administrative login through such a protocol, you can use the /etc/
securetty file to limit logging in to the root account only through the system console.
For instance, to restrict root logins to only the console, create the/etc/security file
with a single line consisting of console. For more information, see login(1).
24 Installing the HP-UX Operating Environment Securely
1.4 Using Boot Authentication to Prevent Unauthorized Access
The boot authentication feature protects single-user mode boot with password
authentication. It makes it possible to configure a system so that only authorized users
are allowed to boot the machine into single-user mode. The boot authentication feature
must be enabled before you reboot the system.
Boot authentication is configured by two attributes in the /etc/default/security
file:
• BOOT_AUTH enables or disables boot authentication. Specify BOOT_AUTH=1 to
enable boot authentication. By default, authentication is disabled (BOOT_AUTH=0).
• BOOT_USERS defines who can log in as root when the boot authentication feature
is enabled. The names listed in BOOT_USERS are separated by commas. For
example:
BOOT_USERS=root,mary,jack,amy,jane
BOOT_USERS=root is the default value.
The /etc/default/security configuration file is explained in Chapter 2 and in
security(4).
1.5 Setting Install-Time Security Options
The Install-Time Security (ITS) options allow you to configure an HP-UX Bastille security
lockdown engine, which can include an HP-UX IPFilter firewall. After system installation
is complete, it will have one of the preconfigured levels of security.
During installation, you can choose from four preconfigured levels of security:
Sec00Tools Install the security infrastructure but without enabling optional security
features. This is the default.
Sec10Host Install a host-based lockdown system, without HP-UX IPFilter firewall
configuration. With this level of security, most network services are
disabled. These services can be reinstated by running the bastille(1M)
command.
Sec20MngDMZ Install a managed lockdown system that blocks most incoming traffic
with an HP-UX IPFilter firewall.
Sec30DMZ Install a DMZ Full lockdown system, which is a host-based and IPFilter
network lockdown. HP-UX IPFilter blocks almost all incoming
connections.
For information on ITS and HP-UX Bastille, see the HP-UX Bastille User Guide:
www.hp.com/go/hpux-security-docs
Click HP-UX Bastille Software.
For information on HP-UX IPFilter, see the HP-UX IPFilter Administrator's Guide:
1.4 Using Boot Authentication to Prevent Unauthorized Access 25
www.hp.com/go/hpux-security-docs
Click HP-UX IPFilter Software.
1.6 Installing Security Patches
Immediately after installation, apply the required and recommended patches using HP-UX
Software Assistant (SWA).
SWA is a command-line-based tool that consolidates and simplifies patch management
and security bulletin management on HP-UX systems. The SWA tool replaces Security
Patch Check (SPC), and is the HP-recommended utility to use to maintain currency with
HP-published security bulletins for HP-UX software.
NOTE: Use of the Software Assistant software tool can help improve system security,
but it does not guarantee system security.
For more information on SWA, see the HP-UX Software Assistant System Administration
Guide:
www.hp.com/go/hpux-security-docs
Click HP-UX Software Assistant (SWA) Software.
1.7 Postinstallation Security Tips for Backup and Recovery
After the system is running, you must still maintain its security. Be diligent in maintaining
system backup and recovery files. Following are some guidelines:
• Use only the fbackup and frecover commands to back up and recover files
selectively. Only fbackup and frecover retain access control lists (ACLs). Use
the -A option of these commands when backing up and recovering files for use on
systems that do not implement ACLs. See fbackup(1M) and frecover(1M).
• If you plan to recover the files to another system, be sure that the user's user name
and group name on both systems are consistent.
• Remember that the backup media is sensitive material. Allow access to the media
only on the basis of proven need.
• Label backup tapes and store them securely. Offsite storage provides maximum
security. Keep archives for a minimum of 6 months, and then recycle the media.
• Perform daily incremental and full weekly backups.
Synchronize the backup schedule with the information flow in your organization.
For example, if a major database is updated every Friday, you might want to
schedule the weekly backup on Friday evenings.
• If you must back up all files on schedule, request that all users log off before
performing the backup. The fbackup command warns you if a file is changing
while the backup is being performed.
26 Installing the HP-UX Operating Environment Securely
• Examine the log file of latest backups to identify problems occurring during backup.
Set restrictive permissions on the backup log file.
• Be aware that the frecover command allows you to overwrite a file. However,
the file retains the permissions and ACLs set when the file was backed up.
• Test the recovery process beforehand to make sure you can fully recover data in the
event of an emergency.
• When recovering files from another machine, you might have to execute the chown
command to set the user ID and group ID for the system on which they now reside,
if the user and group do not exist on the new system. If files are recovered to a new
system that does not have the specified group, the files will take on the group
ownership of the person running the frecover command. If the owner and group
names have different meanings on different systems, recovery results might be
unexpected and not what you wanted.
• Although a power failure should not cause file loss, if someone reports a lost file
after a power failure, look for it in the /lost+found directory before restoring it
from a backup tape.
• To verify contents of the tape being recovered, use the -I option of the frecover
command to preview the index of files on the tape. Existing permissions of a file
system are kept intact by the backup. The frecover command prevents you from
reading the file if the permissions on the file forbid it.
• Never recover in place any critical files, such as /etc/passwd or those in /tcb/
files. Instead, restore the file to a temporary directory (do not use /tmp), and
give this directory permissions drwx------, preventing anyone else from using it.
Compare the restored files with those to be replaced. Make any necessary changes.
• Be sure to turn auditing on. Auditing is not enabled automatically when you have
recovered the system.
1.7 Postinstallation Security Tips for Backup and Recovery 27
28
2 Administering User and System Security
This chapter addresses basic user security after the operating system is installed. It focuses
on logins, passwords, and other user interactions with the system. The following topics
are discussed:
• Managing user access (Section 2.1)
• Authenticating users during login (Section 2.2)
• Authenticating users with PAM (Section 2.3)
• Managing passwords (Section 2.4)
• Defining system security attributes (Section 2.5)
• Handling setuid and setgid programs (Section 2.6)
• Preventing stack buffer overflow attacks (Section 2.7)
• Protecting unattended terminals and workstations (Section 2.8)
• Protecting against system access by remote devices (Section 2.9)
• Securing login banners (Section 2.10)
• Protecting the root account (Section 2.11)
2.1 Managing User Access
Authorized users gain access to the system by supplying a valid user name (login name)
and password. Each user is defined by an entry in the /etc/passwd file. Use the HP
System Management Homepage (HP SMH) to add, remove, deactivate, reactivate, or
modify a user account.
For more information about passwords, refer to passwd(4), passwd(1), and see
Section 2.4 in this document.
2.1.1 Monitoring User Accounts
Following are guidelines for monitoring user accounts:
• Regularly examine the output from the last, lastb, and who commands for unusual
logins.
• Verify that all users with accounts have a legitimate business need to access the
system.
• Be alert for multiple users sharing the same user account. Do not allow two users to
share the same user account.
• Verify that no user accounts share the same user ID (UID).
• Ensure that all accounts have secure passwords that change regularly.
• Verify that all user home directories have the appropriate permissions. Most home
directories have read access but no write access to other users. For better protection,
set the read, write, and execute permissions for the directory owner only.
2.1 Managing User Access 29
• Ensure that all users understand the security policies. Place a company security
policies file in each home directory.
• Examine the /etc/passwd file or other appropriate user database for unused
accounts, and especially for users who have left the company.
• Examine root accounts to see who has root access.
• Consider implementing HP-UX Role-based Access Control to minimize the risks
associated with multiple users having access to the root account. For more
information, see Chapter 8.
• Examine guest accounts to see how often they are used.
2.1.2 Monitoring Guest Accounts
For the highest level of security, do not allow guest or open accounts. If you do have
guest accounts, then do the following:
• Change the guest password frequently. You can specify the password.
• Use a restricted shell (rsh) to limit system access. For information about the rsh
command, refer to sh(1) and sh-posix(1).
• Guest accounts are often forgotten. Use one of the following methods to disable the
guest account when not in use:
— Use per-user security attributes to automatically disable the account after a certain
number of inactive days. For more information, refer to security(4) and see
Section 2.5.2.2.
— Use the following command to lock the guest account:
# passwd -l guest
— Use the following command to delete the guest account:
# userdel guest
• Schedule an at job to automatically lock temporary accounts:
# at now +14 days passwd -l tempacct
• Regularly scan the /var/adm/wtmp and /var/adm/sulog files to check for
unused accounts.
Refer to sh(1) and su(1) for more information.
2.1.3 Creating Application User Accounts
If users only use HP-UX to launch an application, they do not require access to a shell.
These users should only be using the application, such as a database management
system, and not need access to any HP-UX functionality.
To restrict access to HP-UX, modify the /etc/passwd file so that only a specific command
is executed after the user logs in. The /etc/passwd file contains essential information
required during login:
30 Administering User and System Security
• User name
• Encrypted password
• User ID
• Group ID
• Comment field
• Home directory
• Login program
Typically, the login program is a shell, such as /bin/sh, but it does not have to be a
shell. You can create a captive account—an account that logs a user directly into an
application—by identifying the application as the login shell.
Following is an example of restricting a user to run only the date command. The /etc/
passwd entry is:
username:rc70x.4,sx2:20:1:run only date command:/home/date:/usr/bin/date
At the login prompt, a user enters username and the appropriate password. The date
command is executed and then the user is immediately logged out.
login:username
Password:xxxxxx
Tue Nov 14 18:38:38 PDT 2006
2.1.4 Managing Group Accounts
When a group has to share or have access to project-related files, follow these steps to
ensure security:
1. Verify that each member has an entry in /etc/passwd.
2. Create an entry for the group in the /etc/group file.
3. Create a shared directory for the group.
drwxrwx-- root project /home/projects
4. Set the umask in each group member's ~/.profile. In the following example,
users in the group can read, write, and execute files, but no one else can:
umask u=rwx,g=rwx, o=
2.2 Authenticating Users During Login
To gain access to a system and its resources, users are required to log in. By controlling
access to the system, you can try to prevent unauthorized users from accessing the system.
However, even if unauthorized users do gain access, you can still prevent them from
running programs that consume resources and from accessing system data. This section
explains what happens during the login process from the time you type your user name
to the time you get a shell prompt.
2.2 Authenticating Users During Login 31
2.2.1 Explanation of the Login Process
The following steps describe the login process. This information shows how important it
is to create unique user names and to maintain a password security policy. For more
information, refer to login(1).
1. After the system is installed, the desktop Login Manager displays a login screen.
The Common Desktop Environment (CDE) displays a CDE login screen if it is installed.
2. The init program spawns a getty process, which prompts you for a user name.
You enter your user name. The getty program passes the user name to the login
program.
3. The login program searches/etc/passwd for the user name.
• If the user name exists, login goes to step 4 .
• If the user name does not exist, then login does the following checks:
— Prompts for a password (Password: ).
— If an invalid password is entered, the system displays the Invalid login
error message.
— Updates the /var/adm/btmp file if it exists. The /var/adm/btmp file
keeps track of invalid login attempts. See Section 2.2.2 for more information.
— Exits after three consecutive invalid login attempts.
4. The login process verifies the /etc/passwd file.
• If the password field is set, login prompts for a password and goes to step
5.
• If the password field is not set, the user does not need a password and login
goes to step 6 .
5. The login process compares the password to the encrypted password in
/etc/passwd.
• If the password matches, login goes to step 6.
• If the password does not match, login displays Invalid login. The login
process allows three consecutive login attempts. After the user's third invalid
login attempt, login exits.
6. The login process updates the /var/adm/wtmp file, which keeps track of valid
logins. See Section 2.2.2 for more information.
After a successful login, the user and group IDs, group access list, and working
directory are initialized.
7. The login process then runs the command in the command field of the
/etc/passwd file. Typically, the command field is the path name of a shell, such
32 Administering User and System Security
as /bin/ksh, /bin/csh, or /bin/sh. If the command field is empty, the default
is /bin/sh.
The command field does not have to be a shell. See Section 2.1.3 for an example
of running another command.
8. After the shell initialization is complete, the system displays a prompt and waits for
user input.
You can have the login process perform further user authentication using the Pluggable
Authentication Modules (PAM). For more information, see pam.conf(4) and Section 2.3.
2.2.2 Checking the login Tracking Files (btmp and wtmp)
The following files keep a log of logins:
• The /var/adm/btmp file keeps track of failed logins.
• The /var/adm/wtmp file keeps track of successful logins.
Use the lastb command to read the /var/adm/btmp file to see if unauthorized users
have attempted to log in.
Use the last command to read the/var/adm/wtmp file.
The last and lastb commands display the most recent user information, in descending
order.
The wtmp and btmp files tend to grow without bound, so check them regularly.
Periodically remove information that is no longer useful to prevent the file from becoming
too large. The wtmp and btmp files are not created by the programs that maintain them.
If these files are removed, login record keeping is turned off.
A common mistake users make during login is to enter the password, or part of the
password at the login prompt. This failed login is recorded in the btmps file and exposes
the password or partial password. For this reason, the file protection on the btmps should
be set so that it is only readable by administrators.
# chmod 400 /var/adm/btmps
If the security policy requires that past sessions of one user cannot be viewed by another
user, then the file protection of the /var/adm/wtmp file may also need to be changed.
See last(1), utmp(4), and wtmp(4) for more information.
The utmp database is a user accounting database managed and synchronized according
to /var/adm/utmp by the utmpd command. Application programs can access the
utmps database. See utmpd(1M) and utmps(4).
2.2.2.1 Last Command Examples
This section contains examples of using the last command. The following command
lists all of the root sessions and all sessions on the console terminal:
# last root console | more
root pts/1 Mon Mar 12 16:22 - 18:04 (01:41)
2.2 Authenticating Users During Login 33
abcdeux console Mon Mar 12 10:13 - 10:19 (00:06)
root pts/2 Fri Mar 9 13:51 - 15:12 (01:21)
abcdeux console Thu Mar 8 12:21 - 12:22 (00:00)
root pts/ta Wed Mar 7 15:38 - 18:13 (02:34)
The following command lists when reboots have occurred:
# last reboot
reboot system boot Sun Mar 28 18:06 still logged in
reboot system boot Sun Mar 28 17:48 - 18:06 (00:17)
reboot system boot Sun Mar 28 17:40 - 17:48 (00:08)
reboot system boot Thu Feb 19 18:25 - 17:40 (37+23:15)
reboot system boot Mon Feb 16 13:56 - 18:25 (3+04:28)
2.2.3 Checking Who Is Logged In
The who command examines the /etc/utmp file to obtain current user login information.
In addition, the who command can list logins, logoffs, reboots, changes to the system
clock, and processes spawned by the init process.
Use the who -u command to monitor who is currently logged in. For example:
# who -u
aperson console Aug 5 11:28 old 5796 system.home.company.com
aperson pts/0 Aug 17 18:11 0:03 24944 system
aperson pts/1 Aug 5 11:28 1:14 5840 system
See who(1) for more information.
2.3 Authenticating Users with PAM
The Pluggable Authentication Modules (PAM) are an industry-standard framework
providing authentication, account management, session management, and password
services. This section gives an overview of PAM and describes the PAM configuration
files: /etc/pam.conf and /etc/pam_user.conf.
For more information, see pam(3), pam_*(5), pam.conf(4), pam_user.conf(4), and
security(4).
2.3.1 Overview
PAM provides the flexibility to choose any authentication service available on the system.
The PAM framework also enables you to plug in new authentication service modules and
make them available without modifying the applications.
Whenever a user logs in either locally or remotely (for example, using login or rlogin),
the user must be checked or authenticated as a valid user of the system. As authentication
methods improve and change over time, the login services would also have to change.
To avoid constant changing of the login services just to revise the authentication code,
PAM was developed so that different authentication methods can be used without
modifying the login code.
34 Administering User and System Security
As a result, login authentication, account checking, and password modification use the
libpam_ntlm.1
PAM Library
libpam_krb5.1
libpam_unix.1
libpam_ldap.1libpam_dce.1
login
su
passwd telnet
UNIX DCE Kerberos
LDAP NTLM
libpam_radius.1
RADIUS
Use the PAM configuration
file, /etc/pam.conf, to indicate
which authentication module
to use.
Request for
Validation
Authentication Services
PAM interface.
Programs requiring user authentication pass their requests to PAM, which determines the
correct verification method and returns the appropriate response. The programs do not
need to know what authentication method is being used. See Figure 2-1 for an overview.
Figure 2-1 HP-UX Authentication Modules Under PAM
The authentication methods are specified on both a systemwide and individual user basis
using the following PAM system files:
/etc/pam.conf Systemwide control file. Defines which service modules
/etc/pam_user.conf Individual user control file. Defines which options are to
See pam(3), pam.conf(4), pam_updbe(5), pam_user.conf(4) for more information.
are to be paired with services. These are regarded as
system defaults.
be used by service modules on specific users. This is an
optional file.
2.3 Authenticating Users with PAM 35
2.3.2 PAM Libraries
PAM service modules are implemented by shared libraries. PAM enables multiple
authentication technologies to co-exist in HP-UX. The /etc/pam.conf configuration file
determines which authentication module to use. The PAM libraries are as follows:
• PAM_DCE
The PAM_DCE modules enable integration of DCE into the system entry services
(such as login, telnet, rlogin, ftp). The PAM_DCE modules provide
functionality for the authentication, account management, and password management
modules. These modules are supported through the PAM_DCE library, /usr/lib/
security/pam_dce.sl. See pam_dce(5) for more information.
• PAM_HPSEC
The PAM_HPSEC modules manage extensions specific to HP-UX for authentication,
account management, password management, and session management. The use
of /usr/lib/security/$ISA/libpam_hpsec.so.1 is mandatory for services
such as login, dtlogin, ftp, su, remsh, rexec, and ssh. These services must
place libpam_hpsec.so.1 on the top of the stack above one or more nonoptional
modules. The pam_hpsec module also enforces several attributes defined in /etc/
default/security. See pam_hpsec(5) and security(4) for more information.
• PAM_KRB5
Kerberos is a network authentication protocol that enables secure communication
over networks without transmitting passwords in clear text. A password is
authenticated by the Key Distribution Center (KDC), which then issues a Ticket
Granting Ticket (TGT). The PAM Kerberos shared library is /usr/lib/security/
libpam_krb5.1. See pam_krb5(5) for more information.
• PAM_LDAP
The Lightweight Directory Access Protocol (LDAP) is a standard for centralizing user,
group, and network management information through directory services.
Authentication takes place on an LDAP directory server.
For more information, see the HP-UX LDAP-UX Integration Software documentation:
www.hp.com/go/hpux-security-docs
Click HP-UX LDAP-UX Integration Software.
• PAM_NTLM
The PAM NT LAN Manager enables HP-UX users to be authenticated against
Windows servers during system login. PAM NTLM uses NT servers to authenticate
users logging in to an HP-UX system.
For more information, see the HP CIFS Client Administrator's Guide:
http://www.hp.com/go/hpux-networking-docs
36 Administering User and System Security
Click HP-UX 11i v3 Networking Software.
• PAM_RADIUS
The HP-UX PAM RADIUS module provides authentication and session management
for PAM enabled applications (typically system entry services such as login and
ftp) through RADIUS server using the pam.conf configuration file. The HP-UX PAM
RADIUS module consists of the following two modules:
— Authentication module
— Session management module
It also provides null function for account management. All modules are supported
through the same dynamically loadable library,
/usr/lib/security/libpam_radius.1.
The HP-UX PAM RADIUS module supports two-factor authentication by requesting
the user's password and One Time Password (OTP).
For more information, see pam_radius(5).
• PAM_UNIX
The PAM_UNIX modules provide functionality for all four PAM modules:
authentication, account management, session management, and password
management. The modules are supported through the PAM UNIX library, /usr/
lib/security/libpam_unix.1. See pam_unix(5) for more information.
• PAM_UPDBE
The user policy definition service module for PAM, /usr/lib/security/
libpam_updbe.1, reads options defined in the user configuration file, /etc/
pam_user.conf, and stores the information in the PAM handle for subsequent
service modules to use. See pam_updbe(5) for more information.
2.3.3 Systemwide Configuration Using /etc/pam.conf
The PAM configuration file /etc/pam.conf defines the security mechanisms that are
used to authenticate users. Its default values provide the customary operation of the system
under both standard HP-UX and trusted systems. It also provides support for controls on
individual users and for the DCE integrated login functionality.
NOTE: For DCE, use the auth.adm utility to create the desired configuration file. This
file is functionally equivalent to the former HP integrated login auth.conf file. See
auth.adm(1m) for more information.
The libpam and libpam_unix PAM libraries and the /etc/pam.conf configuration
file must be on the system in order for users to be able to log in or change passwords.
HP-UX authentication is dependent upon the file /etc/pam.conf. This file must be
owned by root with the following file permissions:
2.3 Authenticating Users with PAM 37
-r--r--r-- 1 root sys 1050 Nov 8 10:16 /etc/pam.conf
If this file is corrupt or missing from the system, root can log in to the console in single-user
mode to fix the problem.
The protected service names are listed in the system control file, /etc/pam.conf, under
four test categories (module-type): authentication, account, session, and password.
See pam(3), pam.conf(4), and pam_user.conf(4) for more information.
2.3.4 Sample /etc/pam.conf File
Following is a partial listing of a sample /etc/pam.conf file. Lines beginning with
pound (#) are comment lines. The sections in /etc/pam.conf are authentication
management, account management, session management, and password management.
#
# PAM configuration
#
# Notes:
#
# If the path to a library is not absolute, it is assumed to be
# relative to the directory /usr/lib/security/$ISA/
#
# For PA applications, /usr/lib/security/$ISA/libpam_unix.so.1 is a
# symbolic link that points to the corresponding PA (32 or 64-bit) PAM
# backend library.
#
# The $ISA (i.e. Instruction Set Architecture) token will be replaced
# by the PAM engine with an appropriate directory string.
# See pam.conf(4).
#
# Also note that the use of pam_hpsec(5) is mandatory for some of
# the services. See pam_hpsec(5).
#
# Authentication management
#
login auth required libpam_hpsec.so.1
login auth required libpam_hpsec.so.1
su auth required libpam.hpsec.so.1 bypass_setaud
su auth required libpam_unix.so.1
dtlogin auth required libpam_hpsec.so.1
dtlogin auth required libpam_unix.so.1
dtaction auth required libpam_hpsec.so.1
dtaction auth required libpam_unix.so.1
ftp auth required libpam_hpsec.so.1
ftp auth required libpam_unix.so.1
rcomds auth required libpam_hpsec.so.1
rcomds auth required libpam_unix.so.1
sshd auth required libpam_hpsec.so.1
sshd auth required libpam_unix.so.1
OTHER auth required libpam_unix.so.1
#
# Account management
#
login account required libpam_hpsec.so.1
login account required libpam_unix.so.1
38 Administering User and System Security
su account required libpam_hpsec.so.1
su account required libpam_unix.so.1
2.3.5 The /etc/pam_user.conf User Configuration File
The PAM configuration file, /etc/pam_user.conf, configures PAM on a per-user
basis. This file is optional. It is needed only if PAM applications need to behave differently
for different users.
You assign different options to individual users by listing them in /etc/pam_user.conf.
For a login-name listed here, the options listed here replace any options specified
for the module-type and module-path in /etc/pam.conf.
The entries in /etc/pam_user.conf use the following syntax:
login-name module-type module-path options
where:
login-name User's login name.
module-type The module-type specified in /etc/pam.conf.
module-path The module-path associated with module-type in /etc/
pam.conf.
options Zero or more options recognized by the module.
The default contents of /etc/pam_user.conf are comments:
#
# This file defines PAM configuration for a user. The configuration
# here overrides pam.conf.
#
# The format for each entry is:
# user_name module_type module_path options
#
# For example:
#
# user_a auth /usr/lib/security/libpam_unix.1 debug
# user_a auth /usr/lib/security/libpam_dce.1 try_first_pass
# user_a password /usr/lib/security/libpam_unix.1 debug
#
# user_b auth /usr/lib/security/libpam_unix.1 debug use_psd
# user_b password /usr/lib/security/libpam_unix.1 debug use_psd
#
# See the pam_user.conf(4) manual page for more information
#
2.3.6 Examples: How PAM Works for Login
The following examples describe the auth process for login, depending upon how
the /etc/pam.conf file is configured:
• If /etc/pam.conf contains a single standard login auth, such as the following,
then login proceeds normally:
2.3 Authenticating Users with PAM 39
login auth required /usr/lib/security/libpam_unix.1
• If there are two or more systemwide login auth entries, such as the following,
they are taken in order:
login auth required /usr/lib/security/libpam_unix.1
login auth required /usr/lib/security/libpam_dce.1
In this case, the standard HP-UX login process is executed. Then the DCE
authentication process occurs. If both are satisfied, then the login is successful. Both
processes are performed, even if the user fails one of them.
• If you require different authentication methods for different users, place the special
entry libpam_udpbe ahead of the authentication modules in /etc/pam.conf
(the lines are numbered for easy reference):
#/etc/pam.conf
#1
login auth required /usr/lib/security/libpam_udpbe.1
#2
login auth required /usr/lib/security/libpam_unix.1
#3
login auth required /usr/lib/security/libpam_dce.1
Then place entries for each affected user in /etc/pam_user.conf:
#/etc/pam_user.conf
#4
allan auth /usr/lib/security/libpam_unix.1 debug
#5
allan auth /usr/lib/security/libpam_dce.1 try_first_pass
#6
isabel auth /usr/lib/security/libpam_unix.1 debug use_psd
When allan logs in, line 1 in /etc/pam.conf causes PAM to read/etc/
pam_user.conf. Because the module paths on lines 4 and 5 of /etc/
pam_user.conf match the module paths on lines 2 and 3 of /etc/pam.conf,
PAM temporarily replaces the null options fields of lines 2 and 3 of /etc/
pam.conf with debug and try_first_pass, respectively. Then the modules
specified by lines 2 and 3 are executed with the revised options.
When isabel logs in, line 1 in /etc/pam.conf causes PAM to read /etc/
pam_user.conf and temporarily replace the options field of line 2 of /etc/
pam.conf with debug use_psd. Line 3 is unchanged. Then the modules specified
by lines 2 and 3 are executed with the revised options.
When george logs in, line 1 in /etc/pam.conf causes PAM to read /etc/
pam_user.conf. Because entries for george do not exist, lines 2 and 3 of /etc/
pam_user.conf are not changed. The modules specified by lines 2 and 3 are
executed with no changes.
40 Administering User and System Security
2.4 Managing Passwords
The password is the most important individual user identification symbol. With it, the
system authenticates a user to allow access to the system. Because they are vulnerable
to compromise when used, stored, or known, passwords must be kept secret at all times.
The following sections discuss passwords in more detail.
2.4.1 System Administrator Responsibilities
The system administrator and every user on the system must share responsibility for
password security. System administrators perform the following security tasks:
• Ensure that all users have passwords.
• Maintain proper permissions on all system files, including the standard password
and group files, /etc/passwd and /etc/group.
• Delete or nullify user IDs and passwords of users no longer eligible to access the
system.
• Verify that all application passwords are encrypted.
• Verify that permissions on /var/adm/btmp and /var/adm/wtmp are set
appropriately.
• Implement one-time passwords for single guest access.
• Inform users of their responsibilities regarding password security.
• Use password aging to force users to change their passwords regularly.
• Prevent reuse of recent passwords.
• Configure systemwide security attributes in the /etc/default/security file.
See Section 2.5 and refer to security(4) for more information.
• Convert the system to use shadow passwords. See Section 2.4.5 and refer to
shadow(4) and pwconv(1M) for more information.
2.4.2 User Responsibilities
Every user must observe the following rules:
• Remember the password and keep it secret at all times.
• Change the initial password immediately and continue to change it.
• Report any changes in status and any suspected security violations.
• Make sure no one is watching a password being entered.
2.4 Managing Passwords 41
2.4.3 Criteria of a Good Password
Observe the following guidelines when choosing a password and communicate these
guidelines to users:
• Choose a password with at least 6 characters and no more than 80 characters.
Special characters can include control characters and symbols, such as asterisks
and slashes. In standard mode, only the first 8 characters are used.
• Do not choose a word found in a dictionary in any language, even if you spell it
backwards. Software programs exist that can find and match it.
• Do not choose a password easily associated with you, such as a family or pet name,
or a hobby.
• Do not use simple keyboard sequences, such as asdfghjkl, or repetitions of your
login (for example, if your login is ann; a bad password choice is annann).
• Consider using misspelled words or combined syllables from two unrelated words
to make suitable passwords. Another popular method is to use the first characters
of a favorite title or phrase for a password.
• Consider using a password generator that combines syllables to make pronounceable
gibberish.
• Do not share passwords with other users. Management must forbid sharing of
passwords.
• Always have a password. Do not have your password field cleared in the /etc/
passwd file.
2.4.4 Changing the /etc/passwd Password File
A standard system maintains one password file: /etc/passwd.
All passwords are encrypted immediately after entry, and stored in the password file,
/etc/passwd. Only the encrypted password is used in comparisons.
Follow these guidelines if you need to change the password file:
• Do not permit any empty or null password fields; this is a security breach. An empty
password field enables any user to set the password for that account.
• Do not edit the password file directly. Use HP SMH or the useradd, userdel, or
usermod commands to modify password file entries. If you must edit the password
file directly, use the vipw command and check it with the pwck command. See
vipw(1M) and pwck(1M) for more information.
2.4.4.1 Examples of passwd Commands
Following are some useful passwd command examples:
• Reset a user's password:
# passwd user1
• Force a password change at next login:
42 Administering User and System Security
# passwd -f user1
• Lock or disable an account:
# passwd -l user2
• Enable password aging:
# passwd -n 7 -x 28 user1
• View password aging status for a specific user:
# passwd -s user
• View password aging status for all users:
# passwd -sa
2.4.4.2 The /etc/passwd File Format
The /etc/passwd file is used to authenticate a user at login time. The file contains an
entry for every account on the HP-UX system. Each entry consists of seven fields, separated
by colons. A typical /etc/passwd entry looks like this:
robin:Z.yxGaSvxAXGg:102:99:Robin Hood,Rm 3,x9876,408-555-1234:/home/robin:/usr/bin/sh
The fields contain the following information (listed in order), separated by colons:
1. robin—User (login) name, consisting of up to 8 characters.
2. Z.yxGaSvxAXGg—Encrypted password field.
3. 102—User ID, an integer ranging from 0 to MAXINT-1 (equal to 2,147,483,646
or 231-2).
4. 99—Group ID, from /etc/group, an integer ranging from 0 to MAXINT-1.
5. Robin Hood,Rm 3,x9876,408-555-1234—Comment field, used to identify
such information as the user's full name, location, and phone numbers. For historic
reasons, this is also called the gecos field.
6. /home/robin—Home directory, the user's initial login directory.
7. /usr/bin/sh—Login shell path name, executed when the user logs in.
The user can change the password by invoking passwd, the comment field (fifth field)
with chfn, and the login program path name (seventh field) with chsh. The system
administrator sets the remaining fields. The user ID must be unique. See chfn(1), chsh(1),
passwd(1), and passwd(4) for more information.
2.4.5 The /etc/shadow Shadow Password File
Increasing computational power available to malicious password decrytpers has made
the nonhidden passwords in the /etc/passwd file vulnerable to decryption.
A shadow password enhances system security by hiding encrypted passwords in a
shadow password file. You can move encrypted passwords previously stored in the
publicly readable /etc/passwd file to the /etc/shadow file, which is accessible only
by a user with the appropriate privileges.
2.4 Managing Passwords 43
Use the following commands to enable, verify, and disable shadow passwords:
• The pwconv command creates a shadow password file and copies the encrypted
passwords from the /etc/passwd file to the /etc/shadow file.
• The pwck command checks the /etc/passwd and /etc/shadow files for
inconsistencies.
• The pwunconv command copies the encryped passwords and aging information
from the /etc/shadow file to the /etc/passwd file and then deletes the /etc/
shadow file.
For more information, see pwconv(1M), pwck(1M), pwunconv(1M) and shadow(4).
Note the following points about the shadow password feature.
• When the shadow password feature is enabled, applications can be affected if they
directly access the password field of the /etc/passwd file to obtain password and
aging information. That field will now contain an x, indicating that the information
is in /etc/shadow.
Applications that use the PAM interfaces to authenticate, are not effected.
To access the /etc/shadow file programmatically, use the getspent calls. These
calls are similar to the getpwent calls for /etc/passwd. For more information,
see getspent(3C) and getpwent(3C).
• In the /etc/nsswitch.conf file, shadow passwords are supported with files,
NIS, and LDAP name services, but they may not be supported with other name
server switch backends. To configure the system to use only files, NIS, and/or
LDAP, ensure that the passwd line in /etc/nsswitch.conf contains only files,
NIS, and/or LDAP. If /etc/nsswitch.conf does not exist, or if the passwd
line is not present, then the default is files only. For more information, see
nsswitch.conf(4).
• The shadow password is based on the de facto standard provided with other UNIX
systems.
The following attributes, defined in /etc/default/security, apply to shadow
passwords. See Section 2.5 and consult the security(4) manpage for more information.
• INACTIVITY_MAXDAYS—Number of days before expiring an account for inactivity.
• PASSWORD_MINDAYS—Minimum number of days before a password can be
changed.
• PASSWORD_MAXDAYS—Maximum number of days that passwords are valid.
• PASSWORD_WARNDAYS—Number of days before warning users of password
expiration.
Shadow passwords are supported with Serviceguard.
44 Administering User and System Security
NOTE: Shadow passwords are not supported with LDAP-UX. Instead, LDAP-UX provides
the ability to hide user passwords in the directory server itself. LDAP-UX also enforces
centralized security policies, similar to /etc/shadow, based on the security policy of
the directory server.
Shadow passwords are not supported by the applications that expect passwords to reside
in /etc/passwd.
For more information, see the following manpages:
passwd(1), pwck(1M), pwconv(1M), pwunconv(1M), getspent(3C), putspent(3C),
nsswitch.conf(4), passwd(4), security(4), shadow(4)
2.4.6 Eliminating Pseudo-Accounts and Protecting Key Subsystems in /etc/passwd
By tradition, the /etc/passwd file contains numerous “pseudo-accounts,” which are
entries not associated with individual users and which do not have true interactive login
shells.
Some of these entries, such as date, who, sync, and tty, evolved strictly for user
convenience, providing commands that could be executed without logging in. To tighten
security, they have been eliminated in the distributed /etc/passwd so that these
programs can be run only by a user who is logged in.
Other such entries remain in /etc/passwd because they are owners of files. Programs
with owners such as adm, bin, daemon, hpdb, lp, and uucp encompass entire
subsystems, and represent a special case. Because they grant access to files they protect
or use, these programs must be allowed to function as pseudo-accounts, with entries
listed in /etc/passwd. The customary pseudo- and special accounts are shown in
Example 2-1.
Example 2-1 Pseudo- and Special System Accounts
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
nobody:*:-2:-2::/:
The key to the privileged status of these subsystems is their ability to grant access to
programs under their jurisdiction without granting root access (uid 0). Instead, the
setuid bit for the executable file is set and the effective user of the process corresponds
2.4 Managing Passwords 45
to the owner of the executable file. For example, the cancel command is part of the
lp subsystem and runs as effective user lp.
When the setuid is set, the security mediation of that subsystem enforces the security
of all programs encompassed by the subsystem, not the entire system. Hence, the
subsystem vulnerability to a breach of security is also limited to only those subsystem
files. Breaches cannot affect the programs under different subsystems. For example,
programs under lp do not affect those under daemon.
2.4.7 Secure Login with HP-UX Secure Shell
The HP-UX Secure Shell provides secure remote login, file transfer, and remote command
execution. All client-server communication is encrypted. Passwords going across the
network are never sent in clear text. For more information, see ssh(1) and Section 4.6.
2.4.8 Securing Passwords Stored in NIS
The Network Information Service (NIS) is part of the Network File System (NFS). NIS
enables configuration administration of several hosts from a central location, a master
server. Instead of having host configurations stored separately on each host, the
information is consolidated onto a central location. The /etc/password file is among
the several configuration files stored on the NIS server.
The /etc/shadow shadow password file is not supported on NIS.
See the NFS Services Administrator's Guide for information about NIS.
2.4.9 Securing Passwords Stored in LDAP Directory Server
LDAP-UX Client Services interoperates with PAM to authenticate passwords stored on an
LDAP directory server. The PAM_LDAP library provides the authentication service.
2.5 Defining System Security Attributes
Security attributes provide additional control of system configurations, adding security
enhancements to passwords, logins, and auditing.
There are more than 20 attributes. These attributes are described in security(4) . The
categories of attributes are summarized as follows:
Login attributes These attributes control login activities, such as
login times, number of logins allowed, and the
number of login failures allowed before locking
and account.
Password attributes These attributes control password activities, such
as password length, number of characters and
their types, history depth, number of days to
change a password, and password expiration.
46 Administering User and System Security
Boot attributes These attributes control boot authentication,
defining which users are authorized to boot the
system into single-user mode. See boot
authentication information in Chapter 1.
Switch user (su) attributes These attributes define the PATH environment
value, root group name for the su command, and
whether or not su should propagate certain
environment variables. See su(1) for more
information.
Audit attribute This attribute controls whether or not users are to
be audited. The audit attribute is checked during
the login process. See audit(5) for more
information about HP-UX auditing.
umask attribute This attribute controls umask() of all sessions
initiated by pam_unix or pam_hpsec. See
pam_unix(5) and pam_hpsec(5) for more
information. The umask attribute is checked during
the login process.
The system uses these files to process the attributes:
• /etc/default/security
• /var/adm/userdb
• /etc/security.dsc
• /etc/passwd
• /etc/shadow
Each attribute has a per-user value in only one of these locations: /etc/password,
/etc/shadow, or the user database in /var/adm/userdb. Each attribute and its
per-user location are explained in the security(4) manpage.
The system checks what attributes apply in the following ways:
• The system examines the per-user attribute values in the /var/adm/userdb user
database, the /etc/passwd file, or the /etc/shadow file.
• If there is no per-user value, then the system examines the configurable systemwide
default attributes in /etc/default/security.
• If there are no configurable systemwide default attributes, then the system uses the
default attributes in /etc/security.dsc.
The security attributes description file, /etc/security.dsc, lists the attributes you
can define /etc/default/security and in the user database in /var/adm/userdb.
Some attributes are configurable and some are internal. Do not modify the /etc/
security.dsc file in any way.
2.5 Defining System Security Attributes 47
2.5.1 Configuring Systemwide Attributes
The following steps explain how to define security attributes on a systemwide basis.
1. Review the security(4) manpage, which explains the configurable systemwide default
values for attributes. These attributes are configured in the /etc/default/
security file, which is also explained in the security(4) manpage.
If an attribute is not defined in the /etc/default/security file, then the default
value defined in the /etc/security.dsc file will be used by the system. See the
userdb(4) manpage for an explanation of the /etc/security.dsc file.
2. To change a configurable systemwide default, edit the security defaults file, /etc/
default/security, with a text editor such as vi. The file is world readable and
root writable.
Each line in the /etc/default/security file is either a comment or attribute
configuration information. Comment lines begin with a pound (#) sign. Noncomment
lines are in the form of attribute=value pairs, for example,
PASSWORD_MAXDAYS=30.
2.5.2 Configuring Per-User Attributes
Use the following commands to configure specific attributes for individual users. When
you configure per-user attributes, they override the systemwide defaults.
userdbset Changes the attribute for the specified user to override the systemwide
default defined in the /etc/default/security file. For an example,
see Section 2.5.2.1, and see userdbset(1M) for more information.
userdbget Displays the user-defined values for a specific user or all users. See
userdbget(1M) for more information.
userdbck Verifies or fixes the user-defined values. See userdbck(1M) for more
information.
For example, you can change PASSWORD_MAXDAYS from 60 to 30 days only for user
amy. The password for amy is valid for 30 days instead of 60 days. For all other users,
the systemwide value of 60 days applies.
Use the following procedure to change an attribute value for a user:
1. Review the security(4) manpage, which explains the systemwide attributes and
values, and how to set a per-user value. Not all attributes have a per-user value.
2. Review the manpages for the userdbset, userdbget, and userdbck commands.
3. Decide which users to modify and which attributes will apply to them. For example,
you might want to have users in an accounting department change their passwords
every 30 days and a classroom of students change their passwords every quarter.
48 Administering User and System Security
4. Use the userdbset command to change an attribute for a user.
The per-user information is stored in a user database in the /var/adm/userdb
directory. The user database is described in the userdb(4) manpage.
You cannot use the userdbset command to configure all attributes. Some per-user
values are defined in the /etc/passwd and /etc/shadow files. For more
information, see security(4).
5. Use the userdbget command to get user information.
2.5.2.1 Examples of Defining User-Specific Attributes with userdbset
In the following example, the userdbset command deletes all user-defined attributes
for user joe. When joe logs in, the systemwide defaults in /etc/default/security
will then apply to joe.
# /usr/sbin/userdbset -d -u joe
Next, userdbset sets the minimum password length to 7 and sets UMASK to 0022
(octal 022). These changes apply only to joe.
# /usr/sbin/userdbset -u joe MIN_PASSWORD_LENGTH=7 UMASK=0022
In the next example, userdbset displays all attributes for user amy:
# /usr/sbin/userdbget -u amy
amy AUDIT_FLAG=1
amy DISPLAY_LAST_LOGIN=0
In the display, the audit flag is enabled and the last login feature is disabled for amy.
2.5.2.2 INACTIVITY_MAXDAYS and the Shadow Password File
The INACTIVITY_MAXDAYS attribute defined in the /etc/default/security file
controls whether to expire inactive accounts on a systemwide basis. To override the
systemwide default and configure INACTIVITY_MAXDAYS on a per-user basis, use the
useradd -f command or the usermod -f command. Use the userdel command
to delete the per-user configuration. See useradd(1M), usermod(1M), and userdel(1M)
manpages for more information.
You cannot use the userdbset command to configure the INACTIVITY_MAXDAYS on
a per-user basis. The INACTIVITY_MAXDAYS attribute is related to the inactivity field
of the shadow password file. The useradd and usermod commands modify the inactivity
field of the shadow password file for the specified user. See the description of
INACTIVITY_MAXDAYS in the security(4) manpage for more information.
2.5.3 Troubleshooting the User Database
Use the following procedures to troubleshoot the user database.
Problem 1: A user's security attributes seems to be misconfigured. If you suspect that
user information is misconfigured in the user database, run the following command:
2.5 Defining System Security Attributes 49
# userdbget -u username
The attributes configured for the user username are displayed. If an attribute is
misconfigured, reconfigure the attribute.
Problem 2: The user database is not functioning properly. If you need to check the user
database, enter the following command:
# userdbck
The userdbck command identifies and repairs problems in the user database.
2.6 Handling setuid and setgid Programs
Because they pose a potential security risk to the system, note which programs are
setuid (set user ID) and setgid (set group ID) programs. A system attacker can exploit
setuid and setgid programs, most often in one of two ways:
• By having a setuid or setgid program execute commands defined by the attacker,
either interactively or by script.
• By substituting bogus data for the data created by a program.
Follow these guidelines to secure setuid and setgid programs:
• Watch for any changes to setuid and setgid programs.
• Investigate further any programs that appear to be unnecessary setuid programs.
• Change the permission of a program that is unnecessarily a setuid program to a
setgid program. See chmod(1) and chmod(2) for more information.
The long form of the ls command (ll or ls -l) shows setuid programs by listing
S or s instead of - or x for the owner-execute permission. It shows setgid programs
by listing S or s instead of - or x for the group-execute permission.
You can expect to find setuid and setgid system files, but they should have the
same permissions as provided by the factory media, unless you have customized
them.
• Do not allow users to normally have setuid programs, especially when they use
setuid to users other than themselves.
• Examine the code of all programs imported from external sources for destructive
programs known as Trojan Horses. Never restore or install a setuid program for
which you have no source to examine.
• To allow users access to certain superuser programs, HP recommends that you use
Restricted SMH. Restricted SMH allows non-superusers to access particular areas of
SMH. See smh(1M) for details.
50 Administering User and System Security
2.6.1 Why setuid and setgid Programs Can Be Risky
Whenever any program is executed, it creates a process with four ID numbers—real and
effective user ID (ruid and euid) and real and effective group ID (rgid and egid).
Typically, these ID pairs are identical.
However, running a setuid or setgid program changes the euid or egid of the
process from that associated with the owner to that of the object. The processes spawned
acquire their attributes from the object, giving the user the same access rights as the
program's owner and group.
• If the setuid bit is turned on, the privileges of the process are set to that of the
owner of the file.
• If the setgid bit is turned on, the privileges of the process are set to that of the
group of the file.
• If neither the setuid nor the setgid bit is turned on, the privileges of the process
are unchanged.
• As a particularly risky case, if a program is setuid to root, the user gains all
privileges available to root. This is dangerous because the program can be used
in a way that violates system security. To a lesser extent, this problem exists in other
setuid and setgid cases as well.
For security reasons, the setuid and setgid bits on scripts are normally ignored by
the HP-UX kernel. This rule can be relaxed by changing the tunable
secure_sid_scripts, but it is strongly recommended that this tunable be not changed
from the default. For more information on this tunable, see secure_sid_scripts(5).
2.6.2 How IDs Are Set
IDs are set in these different ways:
• The ruid and rgid are inherited from the login process, which sets your uid
and gid. The uid and gid values are specified in /etc/passwd.
• The login command also changes the ruid, euid, rgid, and egid.
• The su command changes the euid and ruid.
• The newgrp command can change the gid.
• Set the setuid and setgid bits by using the chmod system call or chmod
command. See chmod(1) and chmod(2) for more information.
2.6.3 Guidelines for Limiting Setuid Power
Use caution if you add setuid-to-root programs to an existing system. Adding a
setuid-to-root program changes the system configuration and might compromise
security.
2.6 Handling setuid and setgid Programs 51
Enforce restrictive use of privileged programs through the following administrative and
programming recommendations:
• Use setuid and setgid only when absolutely necessary.
• Make sure that no setuid program is writable by others.
• Whenever possible, use setgid instead of setuid to reduce the scope of damage
that might result from coding flaws or breaches of security.
• Periodically search the file systems for new or modified setuid and setgid
programs. You can use the ncheck -s command.
• Know exactly what the setuid and setgid programs do, and verify that they do
only what is intended. Failing this, remove the program or its setuid attribute.
• If you must copy a setuid program, make sure that the modes are correct on the
destination file.
• Write setuid programs so that they can be tested on noncritical data, without
setuid or setgid attributes. Apply these attributes only after the code has been
reviewed and all affected departments are satisfied that the new programs maintain
security.
• Make sure that a setuid program does not create files writable by anyone other
than its intended user.
• Reset the euid before an exec* system call. Be aware that exec* can be called
within other library routines, and be wary of using routines (including popen,
system, execlp, and execvp) that fork a shell to execute a program. See exec(2),
popen(3S), and system(3S) for more information.
• When writing setuid programs, use setresuid around the pieces of code that
require privileges, to reduce the window of vulnerability. See setresuid(2) for more
information.
• Close all unnecessary file descriptors before calling exec*.
• Ensure that all variables (PATH, IFS) and the umask value in the program's
environment are sufficiently restrictive.
• Do not use the creat system call to make a lock file. Use lockf or fcntl instead.
See lockf(2) and fcntl(2) for more information.
• Be especially careful to avoid buffer overruns, for example, by using sprintf,
strcpy, and strcat without proper parameter length validation. See printf(3S)
and string(3C) for more information.
2.7 Preventing Stack Buffer Overflow Attacks
The passing of large amounts of data to a program is called a stack buffer overflow
attack. Usually, the data contains commands that the program is tricked into executing.
These attacks are used to gain unauthorized access to the system, to destroy or alter
data, or to cause denial of service to legitimate users.
To monitor for stack buffer overflow attacks, watch for the following changes:
52 Administering User and System Security
• A setuid program executing other programs.
• A program unexpectedly gaining a user ID of zero (0). The user ID of zero is for
superuser or root only.
To prevent stack buffer overflow attacks:
• Enable the executable_stack kernel tunable parameter.
• Use the chatr +es command.
The executable_stack kernel tunable parameter enables you to prevent a program
from executing code from its stack. This guards against an intruder passing illegal data
to a program, thereby causing the program to execute arbitrary code from its program
stack.
The executable_stack kernel tunable parameter globally enables or disables stack
buffer overflow protection. A setting of 0 (zero) causes stacks to be nonexecutable and
is preferred for security reasons. By default, for backward compatibility,
executable_stack is set to 1, which allows stack execution and therefore no
protection. Use HP SMH or the kmtune command to change the value of
executable_stack.
An additional way to manage stack buffer overflow protection is to use the +es option
of the chatr command. For example, if executable_stack is set to zero but a
program does need to execute its stack, use the following chatr command to allow
stack execution for that program:
# chatr -es enable program
For more information, see chatr(1), kmtune(1M), and executable_stack(5).
2.8 Protecting Unattended Terminals and Workstations
Unattended workstations and terminals are extremely vulnerable to unauthorized users.
Like a front door left unlocked, they are open to anyone. This section explains the following
ways to reduce that risk:
• Control access using /etc/inittab and run levels. Edit /etc/inittab to identify
which devices should run at different run levels.
• Protect terminal device files by denying world access to user terminal sessions.
• Configure the screen lock.
2.8.1 Controlling Access Using /etc/inittab and Run Levels
A run level is a system state in which a specific set of processes is permitted to run. The
processes and default run levels are defined in /etc/inittab. Run levels are 0 through
6, s, or S. If a process is not at the same run level as the system, it is terminated. If a
process is at the same run level, it is started or it continues to execute.
Following is an example to enable terminals and modems to be run at selected run levels.
Both ttp1 and ttp2 are at run levels 2 and 3.
2.8 Protecting Unattended Terminals and Workstations 53
ttp1:23:respawn:/usr/sbin/getty -h tty0p1 9600
ttp2:23:respawn:/usr/sbin/uugetty -h ttypd0p2 9600
Following is an example of changing run levels after normal work hours to disable
terminals and modems using a cron job. During the day, the run level is 3 and the ttp1
and ttp2 terminals can be used because they are at run levels 2 and 3. At 8:00 a.m.
from Monday through Friday, the system run level is set to 3:
# crontab -e
0 8 * * 1-5 /sbin/init 3
0 17 * * * /sbin/init 4
At 5:00 p.m. every day (the 17 in the previous example means 1700 hours or 5:00
p.m.), the system run level is changed to 4. The ttp1 and ttp2 terminals cannot operate
after 5:00p.m. because they are at run levels 2 and 3.
2.8.2 Protecting Terminal Device Files
If an intruder gains access to an open terminal, they can redirect a command to another
terminal window. In the following example, a remove (rm) command is redirected to
/dev/tty0p0:
# echo "\r rm -r / \r\033d" > /dev/tty0p0
To prevent messages from writing to a terminal, you can use the mesg -n (or mesg n)
command. This command revokes write permissions to users who do not have the
appropriate privileges. See mesg(1) and write(1) for more information.
# vi ~/.shrc
mesg n
Another way to protect the workstation or terminal is to use the xhost command. See
xhost(1) for more information. The xhost command defines the names of hosts and users
who are allowed to make connections to the workstation.
# xhost +Another.system
To allow all systems and users to access the workstation, thereby turning access control
off, use the following command:
# xhost +
2.8.3 Configuring the Screen Lock
This section discusses how to configure the screen lock using the TMOUT variable and
the CDE lock manager.
2.8.3.1 Configuring the TMOUT Variable
You can configure the TMOUT variable to automatically lock inactive terminals.
54 Administering User and System Security
If you use other systems often and if you copy the .profile file from one system to
another, then adding the TMOUT variable to the .profile is more convenient. If you
typically stay on one system, then either method of locking the terminal can be used.
To configure the TMOUT variable, edit the .profile file as shown in the following:
# vi ~/.profile
export TMOUT=600 # (lock after 600 seconds of inactivity)
You can change the 600 to another desired value.
2.8.3.2 Configuring the CDE Lock Manager
You can configure the CDE lock manager to lock your screen after a certain amount of
inactive time. To configure the CDE lock manager to lock the screen after 10 minutes of
inactive time, enter the following commands:
# cp /usr/dt/config/C/sys.resources /etc/dt/config/C/sys.resources
# vi /etc/dt/config/C/sys.resources
dtsession*lockTimeout: 10
You can also use the Style Manager task panel to adjust the CDE lock manager. To do
this, click on the screen icon.
2.9 Protecting Against System Access by Remote Devices
To protect against system penetration by remote access, observe the following precautions:
• Require the use of a hardware dial-back system for all interactive modems.
• Require an additional password from modem users by adding an entry for the
modem device in /etc/dialups and, optionally, /etc/d_passwd. See
Section 2.9.1.
• Have users renew their dial-in accounts frequently.
• Cancel system access promptly when a user is no longer an employee.
• Establish a regular audit schedule to review remote usage.
• Connect the modems and dial-back equipment to a single HP-UX system, and allow
network services to reach the destination system from that point.
• Make exceptions to dial-back for UUCP access. Additional restrictions are possible
through proper UUCP configuration. See uucp(1) for more information.
Another potential exception is file transfer via kermit. See kermit(1) for more
information.
• If a security breach with unknown factors occurs, shut down both network and
telephone access and inform the network administrator.
• To maximize security when configuring a dial-back modem system, dedicate the
dial-out mechanism to the dial-out function only. Do not configure it to accept dial-in.
Use another modem on another telephone line for your dial-in service.
2.9 Protecting Against System Access by Remote Devices 55
• Keep telephone numbers for modems unlisted and on a different system from other
business phones. Do not publicize the dial-in phone numbers.
• Physically secure the modems.
• Use caller ID to identify all incoming calls to the modems.
• Do not allow call forwarding or other extra phone services on the modem lines. Do
not use cell phone modems.
• For remote and local access, consider installing an HP-UX AAA server product.
Using the industry-standard Remote Authentication Dial-In User Service (RADIUS)
protocol, the HP-UX AAA Server provides authentication, authorization, and
accounting of user network access at the entry point to a network. See the HP-UX
AAA Server Administrator's Guide for more information.
2.9.1 Controlling Access Using /etc/dialups and /etc/d_passwd
For additional security in identifying remote users, add entries into the /etc/dialups
and /etc/d_passwd files. These files are used to control the dialup security feature of
login. See dialups(4) and login(1) for more information.
If the /etc/dialups file exists, the login process compares the terminal to those listed
in /etc/dialups. If the terminal exists in /etc/dialups, a password is requested
by login. That password is compared to those in /etc/d_passwd.
In addition, the /etc/passwd file is used to verify the password.
Following is an example of configuring the /etc/dialups file:
# vi /etc/dialups (list the terminals that are allowed)
/dev/ttyd0p1
/dev/ttyd0p2
# vi /etc/d_passwd
/usr/bin/sh:xxxencrypted-passwordxxxxxxxxx:comments
/usr/bin/ksh:xxxencrypted-passwordxxxxxxxx:comments
/sbin/sh:xxxencrypted-passwordxxxxxxxxx:comments
The user sees:
Login:
Password:
Dialup password:
To change passwords in /etc/d_passwd, use the passwd command as follows:
# passwd -F /etc/d_passwd shell_path
The shell_path is the shell path listed in /etc/d_passwd.
56 Administering User and System Security
2.10 Securing Login Banners
Login banners are often used to display such system information as the system name,
release version, and purpose of the system. This information can help an unauthorized
user to learn more about the system. Following are some guidelines for creating more
secure login banners:
• Consult the legal department to determine an appropriate message.
• Add a warning to the banner message prohibiting unauthorized use.
• Be consistent in what is displayed in all banners regardless of the login method.
You can modify a banner in the following ways:
• Modify the login banner defined in /etc/copyright and /etc/motd.
• Modify the telnet banner defined in/etc/issue. The telnetd -b banner file
command defines a custom banner. To use /etc/issue as the login banner, add
the following lines to the /etc/inetd.conf file:
telnet stream tcp nowait root /usr/lbin/telnetd \
telnetd -b /etc/issue
When inetd starts telnetd, the banner in /etc/issue is used. See inetd(1M),
telnetd(IM), and inetd.conf(4) for more information.
• Modify the ftp banner defined in /etc/ftpd/ftpaccess, which is the ftpd
configuration file. Other displayed messages are defined in /etc/ftpd/
ftpaccess: greeting, banner, host name, and message. See ftpdaccess(4) and
ftpd(1M) for more information.
Following is an unsecured telnet example showing a login banner:
# telnet computerAmy
The telnet login banner shows the release version and machine type. If an unauthorized
user tries to use telnet to access computerAmy, this might be too much information.
Following is a telnet example showing a more secure login banner:
$ telnet computerMom
Trying...
Connected to computerMom.city.company.com.
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON
**************************************************************
This is a private system operated for Hewlett-Packard company business. Authorization from HP
management is required to use this system. Use by unauthorized persons is prohibited.
*************************************************************
login: Connection closed by foreign host.
2.10 Securing Login Banners 57
2.11 Protecting the root Account
Following are suggestions for protecting the root account:
• Do not share the root password.
• Do not use / as the root home directory.
• Examine output from last -R and lastb -R for unusual or failed root logins and
to see who has logged in as root.
• Examine /var/adm/sulog for attempts to use the su root command.
• Look for unauthorized accounts with a UID of zero (0); use the logins -d
command.
The following sections discuss how to protect the root account in more detail.
2.11.1 Monitoring root Account Access
If you have two or more system administrators that need root access, following are some
suggestions for how to track them:
• Allow only direct root logins on the system console. Create the /etc/securetty
file with the single entry, console, as follows:
#echo console > /etc/securetty
This restriction applies to all login names that have a UID of zero (0). See login(1)
for more details.
• Require administrators to use the su root command from their personal account
to access root. For example:
login:me
$ su root
password:xxxx
• Monitor /var/adm/sulog to see who has accessed root using su.
• Configure a separate root account for each system administrator.
# vipw
root:xxx:0:3::/home/root:/sbin/sh
root1:xxx:0:3::/home/root1:/sbin/sh
root2:xxx:0:3::/home/root2:/sbin/sh
• Monitor each system administrator's history file as follows:
#more ~root1/.sh_history
#more ~root2/.sh_history
• Monitor successful and failed su attempts in /var/adm/syslog.
2.11.2 Using the Restricted SMH Builder for Limited Superuser Access
If you need to give limited superuser access to a nonsuperuser, you can activate the
Restricted SMH Builder. Using the Restricted SMH Builder, you can enable or disable
selected SMH areas for the user. To activate the Restricted SMH Builder, enter:
58 Administering User and System Security
# smh -r
When users with restricted access execute SMH, they will have superuser status in the
defined areas and will only see those SMH areas in the menu. All other areas of SMH
will be hidden from the user. When users without access permissions execute SMH, they
will receive an error message stating they must be superuser.
You can also add more applications to SMH and set them up for restricted access.
2.11.3 Reviewing Superuser Access
The /var/adm/sulog file logs all attempts of the su root command including failures.
Successful attempts are flagged with a plus (+) and failures are flagged with a minus (-).
Only root can view the /var/adm/sulog file. For example:
# su root
Password:
# ll /var/adm/sulog
-rw------- 1 root root 690 Aug 17 19:37 /var/adm/sulog
In the following example, userone has successfully used the su command to access
root. A second user, usertwo, has not been successful. In addition, usertwo has not
been successful in using su to access gooduser1 either.
# more /var/adm/sulog
SU 08/17 19:10 + 0 userone-root
SU 08/17 19:36 - 0 usertwo-root
SU 08/17 19:36 - 0 usertwo-root
SU 08/17 19:36 + 0 userone-root
SU 08/17 19:37 - 0 usertwo-gooduser1
2.11 Protecting the root Account 59
60
3 HP-UX Standard Mode Security Extensions
This chapter describes the HP-UX Standard Mode Security Extensions (HP-UX SMSE). The
following topics are discussed:
• Overview (Section 3.1)
• Security attributes and the user database (Section 3.2)
3.1 Overview
HP-UX Standard Mode Security Extensions (HP-UX SMSE) is a group of features that
enhances both user and operating system security. HP-UX SMSE includes enhancements
or changes to the HP-UX auditing system, passwords, and logins for systems in standard
mode. Previously, these features were supported only on systems converted to trusted
mode. With HP-UX SMSE, you can use these features on a standard mode system.
NOTE: HP does not recommend that you use HP-UX SMSE on systems running in trusted
mode. HP-UX SMSE makes available in standard mode many account and password
policies currently available only by converting an HP-UX system to trusted mode. Policies
configured with HP-UX SMSE are not enforced on systems running in trusted mode.
To determine whether a system has been converted to trusted mode, check for the
following file:
/tcb/files/auth/system/default
If this file exists, the system is running in trusted mode. To convert the system back to
standard mode, use the sam(1M) command.
Refer to security(4) for more information on configurations supported with each of the
HP-UX SMSE security features.
HP-UX SMSE offers a new feature, user database. Previously, all HP-UX security attributes
and password policy restrictions were set on a systemwide basis. The introduction of the
user database enables you to set security attributes on a per-user basis that overrides
systemwide defaults.
The following trusted mode features are available in standard mode with HP-UX SMSE:
• Audit all users and events on a system
• Display the last successful and unsuccessful user logins
• Lock a user account if there are too many authentication failures
• Display password history
• Expire inactive accounts
• Prevent users from logging in with a null password
• Restrict user logins to specific time periods
3.1 Overview 61
• Usage of the userdbset command can be restricted based on a user’s
authorizations. See userdbset(1M) for more information.
• The userstat command displays the account status of local users. It checks the
status of local user accounts and reports abnormal conditions, such as account locks.
See userstat(1M) for more information.
3.2 Security Attributes and the User Database
Previously, in standard mode, all HP-UX security attributes and password policy restrictions
were set on a systemwide basis. The introduction of the user database enables you to
set security attributes on a per-user basis, which override systemwide defaults.
3.2.1 System Security Attributes
A security attribute defines how to control security configurations, such as passwords,
logins, and auditing. The security attributes description file, /etc/security.dsc, lists
the attributes that can be defined either in /etc/default/security, in the user
database in /var/adm/userdb, or in both files. Some attributes are configurable and
some are internal.
CAUTION: Do not modify the /etc/security.dsc file in any way.
When a user logs in, the system checks for applicable security attributes in the following
order:
1. The system examines per-user attributes in the following locations:
• /var/adm/userdb
• /etc/passwd
• /etc/shadow
NOTE: For each per-use attribute, a value is stored in one of the three files
above. Refer to security(4) to see which attributes are stored in each file.
2. If there is no per-user value, then the system examines the configured systemwide
attributes in /etc/default/security.
3. If there are no configured systemwide attributes, then the system uses the default
attributes in /etc/security.dsc.
3.2.2 Configuring Systemwide Attributes
To configure systemwide attributes, follow these steps:
1. Plan your configuration using available resources. Refer to security(4) for information
about configuring systemwide attributes.
62 HP-UX Standard Mode Security Extensions
2. To change a systemwide default, edit the /etc/default/security file with a
text editor such as vi. Comments begin with a pound sign (#). Attributes are written
in attribute=value format.
For example, to set the systemwide minimum number of uppercase characters in a
password to two (2), enter the following values into /etc/default/security:
PASSWORD_MIN_UPPER_CASE_CHARS=2
NOTE: Changes to systemwide security attributes do not take effect immediately.
Password attributes take effect the next time users change their passwords. Login attributes
take effect the next time users log in.
3.2.3 User Database Components
The user database feature of HP-UX SMSE includes files, commands, manpages, and
per-user attributes you can apply to specific users on your HP-UX system. All these elements
of the user database are described in the following sections.
3.2.3.1 Configuration Files
Table 3-1 briefly describes the files you use with the user database.
Table 3-1 User Database Configuration Files
DescriptionFile
3.2.3.2 Commands
Table 3-2 briefly describes the commands you can use to modify and administer entries
in the user database.
Table 3-2 User Database Commands
3.2.3.3 Attributes
The following security attributes are available for individual users:
Stores most per-user information./var/adm/userdb
DescriptionCommand
Changes attribute values configured in the user database.userdbset
Displays attribute values configured in the user database.userdbget
Verifies the integrity of the information in the user database.userdbck
Reports the status of local user accounts.userstat
3.2 Security Attributes and the User Database 63
Table 3-3 User Attributes
DescriptionAttribute
Allows or denies login with a null password.ALLOW_NULL_PASSWORD
Audits or stops auditing the user.AUDIT_FLAG
AUTH_MAXTRIES
PASSWORD_MIN_LOWER_CASE_CHARS
PASSWORD_MIN_UPPER_CASE_CHARS
PASSWORD_MIN_DIGIT_CHARS
PASSWORD_MIN_SPECIAL_CHARS
Defines the number of login failures allowed before a user is locked
out of the system.
Displays information about the user's last login.DISPLAY_LAST_LOGIN
Restricts login time periods.LOGIN_TIMES
Defines the minimum password length.MIN_PASSWORD_LENGTH
Defines the number of simultaneous logins allowed per user.NUMBER_OF_LOGINS_ALLOWED
Defines the password history depth.PASSWORD_HISTORY_DEPTH
Defines the minimum number of lowercase characters required in a
password.
Defines the minimum number of uppercase characters required in a
password.
Defines the minimum number of digit characters required in a
password.
Defines the minimum number of special characters required in a
password.
Defines the umask for file creation.UMASK
NOTE: The previous list contains only security attributes that can be configured in the
user database. For a complete list of HP-UX system security attributes, refer to security(4).
3.2.3.4 Manpages
Table 3-4 briefly describes the manpages you use with the user database.
Table 3-4 User Database Manpages
DescriptionManpage
Provides an overview of the use of the user database.userdb(4)
Describes userdbset functionality and syntax.userdbset(1M)
Describes userdbget functionality and syntax.userdbget(1M)
Describes userdbck functionality and syntax.userdbck(1M)
Describes the userstat functionality and syntax.userstat(1M)
64 HP-UX Standard Mode Security Extensions
3.2.4 Configuring Attributes in the User Database
In previous HP-UX systems, security attributes and password policy restrictions were set
a systemwide basis. With HP-UX SMSE, you can configure some security attributes on
a per-user basis. Attributes configured per-user override systemwide configured attributes.
To modify a user's attribute values, follow these steps:
1. Decide which users to modify and which attributes will apply to them.
For example, you want user joe to be able to log in to the system only from 8am to
5pm on Mondays.
2. Change the attributes using the userdbset command as follows:
# userdbset -u user-name attribute-name=attribute-value
For example, to specify that user joe can log in to the system only from 8am to 5pm,
enter:
# userdbset -u joe LOGIN_TIMES=Mo0800-1700
3.2.5 Troubleshooting the User Database
Use the following procedures to troubleshoot the user database.
Problem 1: A user's security attributes seems to be misconfigured. If you suspect that
user information is misconfigured in the user database, run the following command:
# userdbget -u username
The attributes configured for the user username are displayed. If an attribute is
misconfigured, reconfigure the attribute. Refer to “Configuring Attributes in the User
Database” for instructions.
Problem 2: The user database is not functioning properly. If you need to check the user
database, run the following command:
# userdbck
The userdbck command identifies and repairs problems in the user database.
3.2 Security Attributes and the User Database 65
66
4 Remote Access Security Administration
HP-UX provides several remote access services, such as file transfer, remote login, remote
command execution, management of IP addresses and network clients, routing protocols,
mail exchange, network services, and a security mechanism spawned by inetd, the
Internet super daemon.
This chapter discusses the following topics:
• Overview of internet services and remote access services (Section 4.1)
• The inetd Daemon (Section 4.2)
• Protection against spoofing with TCP wrappers (Section 4.3)
• Secure internet services (Section 4.4)
• Controlling an administrative domain (Section 4.5)
• Securing remote sessions using HP-UX Secure Shell (SSH) (Section 4.6)
4.1 Overview of Internet Services and Remote Access Services
This section provides brief descriptions of the authentication or authorization mechanism
used by various Internet Services, and the security risks.
For more information, see the HP-UX Internet Services Administrator's Guide and Using
HP-UX Internet Services:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
The HP-UX Internet Services provides authentication, either through password verification
or authorization that is set up in a configuration file. See Table 4-1 for a list of Internet
Services components and their access verification or authorization mechanism.
Table 4-1 Internet Services Components and Access Verification, Authorization, and
Authentication
Access Verification, Authorization, or Authentication MechanismInternet Services Component
ftp (file transfer)
rcp (remote copy)
distribution)
remsh, rexec (execute
from remote shell)
Password verification. Also can use Kerberos authentication mechanism
defined in /etc/inetsvcs.conf. See ftp(1).
Entry in $HOME/.rhosts or /etc/hosts.equiv file. Also can use
Kerberos authentication mechanism defined in /etc/inetsvcs.conf.
See rcp(1).
Entry in $HOME/.rhosts or /etc/hosts.equiv file. See rdist(1).rdist (remote file
Entry in $HOME/.rhosts or/etc/hosts.equiv file. Also can use
Kerberos authentication mechanism defined in /etc/inetsvcs.conf.
See remsh(1).
4.1 Overview of Internet Services and Remote Access Services 67
Table 4-1 Internet Services Components and Access Verification, Authorization, and
Authentication (continued)
Access Verification, Authorization, or Authentication MechanismInternet Services Component
rlogin (remote login)
telnet (remote login using
TELNET protocol)
NOTE: Information (including passwords) is passed between two systems in clear text
and is not encrypted. Use Internet Services only between hosts that are well-known and
defined to each other and within a private internal network behind a firewall. When
communicating over an untrusted network, secure the communications using IPSec or
Kerberos
Remote Access Services connect remote systems in a network. By default, the remote
access services function in a nonsecure environment. To function in a secure environment,
enable the Kerberos V5 network authentication. In a nonsecure environment, you must
have a login name and password to access a remote system, and the login name is not
checked for authentication and authorization. In a secure environment, you need not
have a login name and password. When you attempt to connect to a remote system, the
Kerberos protocol checks if the user is allowed to access the remote system.
4.1.1 Securing ftp
Password verification or entry in $HOME/.rhosts or /etc/hosts.equiv
file. Also can use Kerberos authentication mechanism defined in /etc/
inetsvcs.conf. See rlogin(1).
Password verification. If the TAC User ID option is enabled by the telnetd
daemon, telnet uses $HOME/.rhosts or /etc/hosts.equiv file. See
telnet(1) and telnetd(1M).
An unauthorized user might try to gain access to a system by using the ftp command.
Following are some suggestions to prevent this problem:
• Enable ftp logging in /etc/inetd.conf by using the ftpd -l command.
• Review the ftp logs in /var/adm/syslog/syslog.log and /var/adm/
syslog/xferlog for unusual remote access attempts.
See syslogd(1M) and xferlog(5).
• Deny ftp access to guest, root, and other accounts by listing them in /etc/
ftpd/ftpusers.
See ftpusers(4).
• Regularly search and remove users' ~/.netrc files. The .netrc file contains login,
password, and account information used by the ftp autologin process, by the
rexec() library routine, and by the rexec command.
See netrc(4).
68 Remote Access Security Administration
4.1.2 Securing Anonymous ftp
If a $HOME/.rhosts file is put into /home/ftp, then an unauthorized user could use
rlogin to log in as the user, ftp. The .rhosts file specifies hosts and users that are
allowed access to a local account using rcp, remsh, or rlogin without a password.
For more information, see hosts.equiv(4).
Following are some suggestions to making anonymous ftp more secure:
• Make sure that neither /home/ftp nor any of its children is writable:
$chmod -R a -w /home/ftp
• Make sure that the ftp entry in /etc/passwd is correctly configured:
ftp:*:500:100:Anonymous FTP user:/var/ftp:/usr/bin/false
• Make sure that all passwords in ~ftp/etc/passwd are asterisks (*):
$more ~ftp/etc/passwd
root:*:0:3::/:/usr/bin/false daemon:*:1:5::/:/usr/bin/false
• If you must have a writable pub directory, use 1733 permissions:
$chmod 1733 /home/ftp/pub
• Use disk quotas or a cron job to control the size of /home/ftp/pub:
0 1 * * * find /home/ftp/pub/* -atime +1 exec rm -rf {} \;
• Check anonymous ftp activity in /var/adm/syslog/syslog.log:
$tail /var/adm/syslog/syslog.log
4.1.3 Denying Access Using /etc/ftpd/ftpusers
The inetd daemon runs the file transfer protocol server, ftpd, when a service request
is received at the port indicated in /etc/services. The ftpd server rejects remote
logins to local user accounts which are listed in /etc/ftpd/ftpusers. These user
accounts are known as restricted accounts. See ftpd(1M), privatepw(1), and services(4).
In the /etc/ftpd/ftpusers file, each restricted account name must appear by itself
on a line. Also add user accounts with restricted login shells that are defined in /etc/
passwd, because ftpd accesses local accounts without using their login shells.
If /etc/ftpd/ftpusers does not exist, ftpd does not perform a security check. For
more information, see ftpusers(4).
On HP-UX 11i, the ftpd daemon is based on WU-FTPD. WU-FTPD is the HP
implementation of the ftpd daemon developed at Washington University. WU-FTPD
includes increased access control, enhanced logging capabilities, virtual hosts support,
and RFC1413 (Identification Protocol) support.:
For more information, see the HP-UX Remote Access Services Administrator's Guide:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
4.1 Overview of Internet Services and Remote Access Services 69
4.1.4 Other Security Solutions for Spoofing
Spoofing is a method of pretending to be a valid user or host to gain unauthorized access
to a system. Because IP addresses and hostnames can be spoofed, using the
/var/adm/inetd.sec security file for inetd (the internet daemon) is not a guaranteed
security solution. See Section 4.2 for information about inetd.
The following security features or products are alternative security solutions:
• IPFilter is a TCP/IP packet filter suitable for use as a system firewall to protect
application servers.
For information on HP-UX IPFilter, see the HP-UX IPFilter Administrator's Guide:
www.hp.com/go/hpux-security-docs
Click HP-UX IPFilter Software.
• TCP Wrappers provides a TCP wrapper daemon, tcpd, that is invoked by inetd
to provide additional security. For more information, see Section 4.3 and the HP-UX
Internet Services Administrator's Guide:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
• Secure Internet Services allows use of Kerberos authentication and authorization for
ftp, rcp, remsh, rlogin, and telnet. Instead of user passwords, encrypted
Kerberos authentication records transmit over the network. For more information,
see the following:
— Section 4.4
— Installing and Administering Internet Services:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
— Configuration Guide for Kerberos Client Products on HP-UX:
www.hp.com/go/hpux-security-docs
Click HP-UX Kerberos Data Security Software.
• IPSec, an IP security protocol suite, provides security for IP networks such as data
integrity, authentication, data privacy, application-transparent security, and
encryption.
For information on HP-UX IPSec, see the HP-UX IPSec Administrator's Guide:
www.hp.com/go/hpux-security-docs
Click HP-UX IPSec Software.
4.2 The inetd Daemon
The Internet daemon, /usr/sbin/inetd, is the master server for many Internet Services.
70 Remote Access Security Administration
The inetd daemon is usually started automatically by the /sbin/init.d/inetd
script as part of the boot process.
The inetd daemon monitors for connection requests for the services listed in the /etc/
inetd.conf configuration file, and spawns the appropriate server on receiving a
request. In other words, users connect to remote systems by using an Internet Service,
such as telnet. The inetd daemon determines if a telnet connection from the host
is allowed before completing the connection. The host information for allowing or denying
access is in the /var/adm/inetd.sec file.
The inetd daemon works as follows:
1. Starts at run level 2 during system boot. (if the following command is in the system
startup script: /sbin/init.d/inetd start)
2. Checks /etc/inetd.conf to determine which services to provide. For more
information, see ftp(1) and inetd.conf(4).
3. Checks /etc/services to determine which ports to monitor for the services listed
in /etc/inetd.conf. The /etc/services file maps service names to port
numbers. For more information, see services(4).
4. Receives an Internet Service connection request from a client. For example, someone
runs telnet.
5. Consults /var/adm/inetd.sec to determine if the client is permitted access. For
more information, see inetd.sec(4).
6. Logs the request in /var/adm/syslog/syslog.log if logging is enabled. For
more information, see syslogd(1M).
7. If inetd refuses the connection for security reasons, the connection is shut down.
8. If the connection request is valid, inetd starts a server process to handle the valid
connection request. The server process can have other security features in addition
to inetd.
4.2.1 Securing inetd
The /etc/inetd.conf file is the inetd configuration file, which lists the services that
the inetddaemon can start. Each service listed in /etc/inetd.conf must also appear
in the /etc/services file. The /etc/services file maps service names to port
numbers. Each port number has an associated protocol name, such as tcp or udp. Every
entry for a protocol must have a matching entry in the /etc/protocols file.
The following suggestions can make inetd more secure:
• Enable inetd logging in /etc/rc.config.d/netdaemons. For more
information, see rc.config.d(4).
• Review /etc/inetd.conf and /etc/services for changes. An unauthorized
user might have gained root access and modified the /etc/services and /etc/
inetd.conf files. In /etc/inetd.conf, look for names of services you are not
using. In /etc/services, look for port numbers that are not registered with the
4.2 The inetd Daemon 71
Internet Assigned Numbers Authority (IANA) at http://www.iana.org. Verify that
the port numbers listed for Internet Services match port numbers registered with
IANA.
• Comment out unnecessary services, such as finger, in /etc/inetd.conf. The
finger command displays user information without needing a password.
• Comment out Remote Procedure Calls (RPC) services in /etc/inetd.conf.
• Comment out inetd "internal trivial" services in /etc/inetd.conf to avoid
denial-of-service attacks. A malicious user might overload inetd with chargen
(character generator) requests. For more information, see inetd(1M) and inetd.conf(4).
4.2.1.1 Denying or Allowing Access Using /var/adm/inetd.sec
In addition to configuring the /etc/inetd.conf file, you can configure an optional
security file called /var/adm/inetd.sec to restrict access to the services started by
inetd. The /var/adm/inetd.sec file lists which hosts are allowed or denied access
to each service. For more information, see inetd.conf(4).
For example:
login allow 10.3-5 192.34.56.5 ahost anetwork
login deny 192.54.24.5 cory.example.edu.testlan
4.3 Protection Against Spoofing with TCP Wrappers
Transmission Control Protocol (TCP) Wrappers provide enhanced security for services
spawned by inetd. TCP Wrappers are an alternative to using /etc/inetd.sec. TCP
Wrappers provide protection against host name and host address spoofing. Spoofing
is a method of pretending to be a valid user or host to gain unauthorized access to a
system.
To prevent spoofing, TCP Wrappers uses Access Control Lists (ACLs). The ACLs are lists
of systems in the /etc/hosts.allow and /etc/hosts.deny files. TCP Wrappers
provide some protection against IP spoofing when configured to verify host name to IP
address mapping and to reject packets with IP source routing.
However, TCP Wrappers do not provide cryptographic authentication or data encryption.
Like inetd, information is passed in clear text.
TCP Wrappers are part of the HP-UX Internet Services software. For more information,
see the HP-UX Internet Services Administrator's Guide:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
You can also see the following manpages:
tcpd(1M), tcpdmatch(1), tcpdchk(1), tcpd.conf(4), hosts_access(3), hosts_access(5), and
hosts_options(5).
72 Remote Access Security Administration
When you enable TCP Wrappers, inetd runs a TCP wrapper daemon, tcpd, instead
of running the requested service directly. The TCP Wrappers work as follows:
1. Clients send connection requests to inetd as they normally do, for example,
telnet.
2. Instead of invoking the server process, inetd calls the TCP Wrapper daemon
(tcpd).
3. The TCP Wrapper daemon determines the validity of the client's connection request.
The tcpd daemon logs the request and checks the access control files (/etc/
hosts.allow and /etc/hosts.deny).
4. If the client is valid,tcpd calls the appropriate server process.
5. The server process processes the client's request, for example, the telnet connection
completes.
4.3.1 Additional Features of TCP Wrappers
You can also define configuration parameters in the /etc/tcpd.conf configuration
file, such as logging behavior, user name lookups, and reverse look up failure behavior.
The tcpd daemon reads this configuration file to look for configuration parameters
during run time.
You can configure the /etc/hosts.allow and /etc/hosts.deny files for other
security features, such as trap setting and banner message.
The trap setting feature of TCP Wrappers enables you to trigger appropriate action on
the host depending upon the number of denied connection attempts from a remote host.
The banner message feature causes a message to be sent to the client when an ACL rule
is included in an access control file.
4.3.2 TCP Wrappers Do Not Work with RPC Services
TCP Wrappers do not work with remote procedure call (RPC) services over TCP. These
services are registered as rpc or tcp in the /etc/inetd.conf file. The only important
service that is affected by this limitation is rexd, used by the on command.
4.4 Secure Internet Services
Secure Internet Services (SIS) is an optionally enabled mechanism that incorporates
Kerberos V5 authentication and authorization for remote access services: ftp, rcp,
remsh, rlogin, and telnet.
Secure Internet Services is part of the HP-UX Internet Services product, which is
documented in Using HP-UX Internet Services:
http://www.hp.com/go/hpux-networking-docs
Click HP-UX 11i v3 Networking Software.
You can also see the following manpages:
4.4 Secure Internet Services 73
sis(5), kinit(1), klist(1), kdestroy(1M), krbval(1M), k5dcelogin(1M), inetsvcs_sec(1M),
and inetsvcs(4).
When you run SIS commands, the security is enhanced because you no longer have to
transmit a password in readable form over the network.
NOTE: The SIS libraries do not encrypt the session beyond what is necessary to
authorize you or to authenticate the service. Therefore, these services do not provide
integrity checking or encryption services on the data or on remote services. To encrypt
the data, use OpenSSL. For more information, see the OpenSSL Release Notes:
www.hp.com/go/hpux-security-docs
Click HP-UX OpenSSL Software.
When two systems are operating in a Kerberos V5-based secure environment, Secure
Internet Services ensures that a local and remote host are identified to each other in a
secure and trusted manner and that the user is authorized to access the remote account.
For ftp/ftpd, rlogin/rlogind, and telnet/telnetd, the Kerberos V5
authentication mechanism sends encrypted tickets instead of a password over the network
to verify and to identify the user. For rcp/remshd and remsh/remshd, the secure
versions of these services ensure that the user is authorized to access the remote account.
4.5 Controlling an Administrative Domain
All network administration programs should be owned by a protected, network-specific
account, such as uucp, nso, or by a daemon, instead of by root.
An administrative domain is a group of systems connected by network services that allow
users to access one another without password verification. An administrative domain
assumes that system users have already been verified by their host system. Use the
following steps to identify and control an administrative domain:
1. List the nodes to which you export file systems in /etc/exports. The /etc/
exports file contains entries of a file system path name and a list of systems or
groups of systems that are allowed access to the file system. The /etc/exports
entries might contain names of groups of systems. You can find out what individual
systems are included in a group by checking /etc/netgroup.
2. List the nodes that have equivalent password databases in /etc/hosts.equiv.
3. Verify that each node in the administrative domain does not extend privileges to
any nodes that are not included. Repeat steps 2 and 3 for each node in the domain.
4. Control root and local security on every node in the administrative domain. A user
with superuser privileges on any machine in the domain can acquire those privileges
on every machine in the domain.
74 Remote Access Security Administration
5. Maintain consistency of user name, uid, and gid among password files in the
administrative domain.
6. Maintain consistency among any group files on all nodes in the administrative
domain. For example, to check consistency with the hq and mfg systems, if the root
file system of the mfg system is remotely mounted to hq as /nfs/mfg/, enter the
following diff command:
$diff /etc/group /nfs/mfg/etc/group
If any differences are displayed, the two /etc/group files are inconsistent and
they should not be.
4.5.1 Verifying Permission Settings on Network Control Files
The network control files in the /etc directory are security targets because they provide
access to the network itself. Network control files should never be writable by the public.
Set the modes, owners, and groups on all system files carefully. Check these files regularly
for any changes and correct any changes.
The most commonly used network control files are as follows:
• /etc/exports
List of file directories that can be exported to NFS clients. For more information, see
exports(4).
• /etc/hosts
List of network hosts and their IP addresses. For more information, see hosts(4).
• /etc/hosts.equiv
List of remote hosts that are allowed access and that are equivalent to the local host.
For more information, see hosts.equiv(4).
• /etc/inetd.conf
Internet Services configuration file. For more information, seeinetd.conf(4).
• /etc/netgroup
List of networkwide groups. For more information, seenetgroup(4).
• /etc/networks
List of network names and their network numbers. For more information, see
networks(4).
• /etc/protocols
List of protocol names and numbers. For more information, see protocols(4).
• /etc/services
List of official service names and aliases with the port number and protocol that the
services use. For more information, see services(4).
4.5 Controlling an Administrative Domain 75
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH)
HP-UX Secure Shell is based on the OpenSSH product, an open source SSH product
(http://www.openssh.org). It enables a secure connection between a client and a remote
host over an otherwise insecure network. Following are the key attributes of this secure
connection:
• Strong authentication for both client and the remote host.
• Strong encryption and public key cryptography for communication between a client
and the remote host.
• A secure channel for the client to use to execute commands on the remote host.
HP-UX Secure Shell offers a secure replacement for such commonly used functions and
commands as telnet, remsh, rlogin, ftp, and rcp.
For HP-UX Secure Shell documentation see the ssh(1) manpage for the ssh client and to
the sshd(8) manpage for the sshd server. Both manpages include references to the other
HP-UX Secure Shell manpages that come with the product.
Also see the HP-UX Secure Shell Release Notes:
www.hp.com/go/hpux-security-docs
Click HP-UX 11i Secure Shell Software.
4.6.1 Key Security Features of HP-UX Secure Shell
The key security features of HP-UX Secure Shell include the following:
• Strong encryption
All communication between the client and the remote host is encrypted using
patent-free encryption algorithms, such as Blowfish, 3DES, AES, and arcfour.
Authentication information, such as passwords, is never sent in clear text across the
network. Encryption in conjunction with strong public key-based cryptography also
provides protection against potential security attacks.
• Strong authentication
HP-UX Secure Shell supports a strong set of authentication methods between client
and server. The authentication can be two-way: the server authenticates the client,
and the client authenticates the server. This protects the session against a variety of
security issues. The supported authentication methods are described Section 4.6.5.
• Port forwarding
The redirection of TCP/IP connections between a client and a remote host (and back)
is referred to as port forwarding or SSH tunneling. HP-UX Secure Shell supports port
forwarding. For example, ftp traffic between a client and a server (or email traffic
between an email client and a POP/IMAP server) can be redirected using port
forwarding. Instead of the client directly communicating with its server, the traffic
76 Remote Access Security Administration
can be redirected to an sshd server over a secure channel, and the sshd server
can then forward the traffic to a designated port on the real server machine.
• Integration with underlying HP-UX security features.
The HP-UX Secure Shell product is integrated with important HP-UX security features.
For more information, see Section 4.6.7.
4.6.2 Software Components of HP-UX Secure Shell
HP-UX Secure Shell software consists of a set of client and server components. See
Table 4-2.
Table 4-2 Software Components of HP-UX Secure Shell
ssh
ssh-rand-helper
ssh-agent
telnet and remsh; it is most similar to
remsh with security features
when sshd is not able to find /dev/random
or /dev/urandom on the server. HP-UX is
shipped with a kernel-resident random number
generator, rng. If rng is deconfigured, sshd
uses prngd.
client to server
LocationDescriptionComponent
ClientSecure Shell client is a secure replacement for
ClientSymbolic link to sshslogin
ServerSecure shell daemonsshd
Client and serverTool for "automatic" key-based login from
Equivalent
non-secure
component(s)
remsh, telnet,
rlogin
remsh, telnet,
rlogin
rcpClient and serverSecure copy client and secure copy serverscp
ftpClientSecure ftp clientsftp
remshd, telnetd,
rlogind
ftpdServerSecure ftp daemonsftp-server
Not applicableServerRandom number generator, which is used
rhosts file
mechanism
ssh-add
ssh-keygen
Not applicableClientTool for making key pairs of the client known
to ssh-agent
Not applicableClientTool for generating key pairs for public key
authentication
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH) 77
Table 4-2 Software Components of HP-UX Secure Shell (continued)
ssh-keyscan
a set of hosts running the Secure Shell daemon
(sshd)
ssh-keysign
during host based authentication is and it is
used by ssh() to access the local host keys host
based authentication
4.6.3 Running HP-UX Secure Shell
Before running any of the Secure Shell clients listed in Table 4-2, first start the Secure
Shell server daemon, sshd. The sshd daemon obtains its initial configuration values
from the sshd_config file, located in the /opt/ssh/etc directory on the server
system. One of the most important configuration directives in sshd_config is the set
of authentication methods supported by the sshd daemon. See Section 4.6.5 for more
information.
4.6.3.1 Running the ssh Client
The ssh client application establishes a socket connection with the sshd server. The
sshd server spawns a child sshd process. This child inherits the connection socket and
authenticates the client based on the selected authentication method. A successful secure
client session is established only upon successful authentication.
After a session is created, all subsequent communication occurs directly between the
client and this child sshd process. The client can now execute remote commands on the
server. Each command request from the ssh client causes the child sshd process to
spawn a shell process to execute that command.
In summary, a running ssh client-server session consists of the following processes:
LocationDescriptionComponent
Equivalent
non-secure
component(s)
Not applicableClientTool for a client to gather the public keys for
Not applicableClientTools to generate the digital signature required
• On every client system connected to the sshd server, there is one ssh client process
for each ssh connection currently established from that client system.
• On the server system, there is one parent sshd process and as many child sshd
processes as there are concurrent ssh clients connected to the server. The number
of child sshd processes running on the server doubles if privilege separation is
enabled on the server. See Section 4.6.4.
• On the server system, for each command execution request from a ssh client, the
corresponding child sshd process spawns a shell process, and uses a UNIX pipe
to communicate the command request to this shell process. This shell process returns
the command execution results to the child sshd process using the UNIX pipe and
terminates when the command execution is complete.
78 Remote Access Security Administration
4.6.3.2 Running the sftp Client
The sftp client application causes the sftp client process to spawn the ssh client, and
then communicates with it using a UNIX pipe. The ssh client then establishes a socket
connection with the sshd server.
The rest of the server interaction is similar to the ssh client case described in
Section 4.6.3.1. The difference is that instead of spawning a shell to execute the remote
command, the child sshd process spawns the sftp-server process. All subsequent
communication during this sftp session occurs among the following processes:
• The sftp client and the ssh client, on the client system, using a UNIX pipe.
• The ssh client and the child sshd process, over the established connection socket.
• The child sshd process and the sftp server process, using a UNIX pipe.
4.6.3.3 Running the scp Client
The scp client case is almost identical with the sftp client execution. The difference is
that instead of spawning the sftp-server process, the child sshd process spawns
the scp process. All subsequent communication during the scp session occurs among
the following processes:
• The scp client and the ssh client, on the client system using a UNIX pipe.
• The ssh client and the child sshd process, over the established connection socket.
• The child sshd process and the scp server process, using a UNIX pipe.
4.6.4 HP-UX Secure Shell Privilege Separation
HP-UX Secure Shell offers a more enhanced level of security through the privileged
separation feature. As described in Section 4.6.3, both the parent sshd and the child
sshd processes run as privileged users. When privilege separation is enabled, one extra
process is spawned per user connection.
When an ssh client connects to an sshd server which is configured for privilege
separation, the parent sshd process spawns a privileged child sshd process. When
privilege separation is enabled, the child sshd process spawns an additional
nonprivileged child sshd process. This nonprivileged child sshd process then inherits
the connection socket. All subsequent communication between client and server occurs
with this nonprivileged child sshd process.
Most remote command execution requests from the client are nonprivileged, and are
handled by a shell spawned under this nonprivileged child sshd process. When the
nonprivileged child sshd process needs a privileged function to be executed, it
communicates with its privileged parent sshd process using a UNIX pipe.
Privilege separation helps contain potential damage from an intruder. For example, if a
buffer overflow attack occurs during a shell command execution, control is within the
nonprivileged process, thereby containing the potential security risk.
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH) 79
NOTE: Privilege separation is the default configuration for HP-UX Secure Shell. You
can turn off privilege separation by setting UsePrivilegeSeparation NO in the
sshd_config file. Because of the potential security risk, turn off privilege separation
only after careful consideration.
4.6.5 HP-UX Secure Shell Authentication
HP-UX Secure Shell supports the following authentication methods:
• GSS-API (Kerberos-based client authentication)
• Public key authentication
• Host-based authentication
• Password authentication
When a client connects with a remote sshd daemon, it selects the desired authentication
method (one of the methods listed previously), and either presents the appropriate
credentials as part of the connection request or responds to a prompt sent back by the
server. All authentication methods work in this way.
The server requires the appropriate key, pass phrase, password, or credentials from the
client to establish a successful connection.
You can choose to have the sshd instance support only a subset of the supported
authentication methods based on security requirements.
Although HP-UX Secure Shell supports the authentication methods listed previously, system
administrators can limit the authentication methods offered by an sshd instance, based
on the specific security requirements of their environment. For example, an HP-UX Secure
Shell environment can dictate that all clients must authenticate using the public key or
Kerberos methods. As a result, may disable the remaining methods. The enabling and
disabling of supported authentication methods is through configuration directives specified
in the sshd_config file.
When an ssh client connection request is made, the server first responds with its list of
supported authentication methods. This list represents the authentication methods supported
by the sshd server and the sequence in which these methods will be tried. The client
can omit one or more of those authentication methods. The client can also change the
sequence in which the methods are attempted. You achieve this with a configuration
directive in the client configuration file, /opt/ssh/etc/ssh_config.
The authentication methods supported by HP-UX Secure Shell are summarized in the
following sections.
4.6.5.1 GSS-API
With the Generic Security Service application Programming Interface (GSS-API), a
Kerberos-based client authentication, the client must obtain Kerberos credentials in
advance, and also have a Kerberos configuration file present in the appropriate client
80 Remote Access Security Administration
directory. When a client connects with an sshd daemon, it presents its credentials at
connection time. The server matches these credentials with its copy of credentials for this
specific user. Also, the server can optionally establish the legitimacy of the client's host
environment.
For more information, see gssapi(5), kerberos(9) and the HP-UX Kerberos Data Security
documentation:
www.hp.com/go/hpux-security-docs
Click HP-UX Kerberos Data Security Software.
4.6.5.2 Public Key Authentication
For public key authentication, the Secure Shell environment must have the following setup:
• Both the client and server must have a key pair. Every ssh client and every sshd
server must generate a key pair for themselves using the ssh-keygen utility.
• The client must make its public key known to all sshd servers it needs to communicate
with. Do this by copying every client's public key into a predetermined directory on
every relevant server.
• The client must acquire the public key for every server it needs to communicate with.
The client acquires the public keys using the ssh-keyscan utility.
After this setup is completed, ssh clients connecting to sshd servers are authenticated
using public and private keys. For more information on public key cryptography, see
public key cryptography.
HP-UX Secure Shell offers an additional feature for streamlining public key authentication.
For some environments, you might want the convenience of not having to respond to
password prompts all the time. You can eliminate the need to respond to password
prompts by using a combination of the ssh-agent and ssh-add processes, both
running on the client machine. The client registers all its key information with the
ssh-agent process through the ssh-add utility. Then, public key authentication between
client and server is facilitated by ssh-agent without the sshd daemon having to interact
with the client.
4.6.5.3 Host-Based and Public Key Authentication
Host-based and public key authentication is a more secure extension of the public key
authentication method. In addition to having key pairs for both client and server, this
method enables client environments to restrict the servers that they will communicate with.
Implement this restriction by creating a .rhosts file in the client's home directory.
4.6.5.4 Password Authentication
The password authentication method relies on the existence of a single user ID and
password-based login. This login could be based on the user's login specified in /etc/
passwd, or it could be PAM-based.
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH) 81
HP-UX Secure Shell is fully integrated with PAM modules available on the server system.
For this purpose, the /opt/ssh/etc/sshd_config file carries a UsePAM configuration
directive. If set to YES, any password authentication request from the client causes sshd
to look at the PAM configuration file (/etc/pam.conf). Password authentication is then
done through the configured PAM modules, in sequence, until successful. For more
information on PAM authentication, see pam.conf(4).
Set the UsePAM directive to NO to ignore PAM authentication. Then any password
authentication request from the client causes sshd to ignore PAM configuration settings
on the server. Instead, sshd obtains user password information by directly calling the
getpwnam library call
HP-UX Secure Shell has been tested with PAM_UNIX, PAM_LDAP and PAM_KERBEROS.
It is also expected to work with other PAM modules, such as PAM_DCE and PAM_NTLM.
4.6.6 Communication Protocols
HP-UX Secure Shell users can connect with a remote sshd daemon using the SSH-1 or
SSH-2 protocol. SSH-2 is more secure, and is strongly recommended instead of SSH-1.
4.6.7 HP-UX Secure Shell and the HP-UX System
HP-UX Secure Shell is actually not a true shell. It is a mechanism for creating a secure
connection between a client and a remote host to execute remote shell sessions securely
on the host. To achieve the secure connection, HP-UX Secure Shell does most of the
authentication and session creation itself. Following is a partial list of features that HP-UX
Secure Shell uses:
• Logging of login attempts
Like telnet or remsh, HP-UX Secure Shell logs successful and unsuccessful sessions
in the /var/adm/wtmp and /var/adm/btmp files, respectively. For more
information, see utmp(4).
• PAM modules
As described in Section 4.6.5, HP-UX Secure Shell can use PAM authentication for
client sessions. When PAM authentication is selected, HP-UX Secure Shell uses the
/etc/pam.conf file and invokes the appropriate PAM module for authentication.
See pam.conf(4) for more information about the /etc/pam.conf file.
• Use of /etc/default/security file
This is a systemwide configuration file that contains attributes defining the behavior
of login, passwords, and other security configurations. HP-UX Secure Shell allows
use of these attributes with some restrictions, which are explained in the /opt/ssh/
README.hp file for HP-UX Secure Shell.
More information on the /etc/default/security file is in security(4).
82 Remote Access Security Administration
• Shadow passwords
HP-UX Secure Shell is integrated with the HP-UX shadow password feature. For more
information, see shadow(4).
• Control system log (syslog)
HP-UX Secure Shell uses syslog to write important messages. For more information,
see syslog(3C) and syslogd(1M).
• Audit logging
HP-UX Secure Shell has implemented audit logging (in trusted mode) in its own code.
For more information, see audit(5).
4.6.8 Associated Technologies
HP-UX Secure Shell has been tested with the following technologies:
• Kerberos 5 and GSS-API
• OpenSSL
• IPv6
• TCP Wrappers
• PAM (PAM_UNIX, PAM_Kerberos, PAM_LDAP)
• HP-UX Strong Random Number Generator
4.6.9 Strong Random Number Generator Requirement
As with all cryptographic key-based products, HP-UX Secure Shell requires a random
number generator. It looks for the HP-UX Strong Random Number Generator special
device files, /dev/urandom and /dev/random, and uses the first special device file
it locates. If these two files do not exist on the system, HP-UX Secure Shell uses its own
internal random number generator, ssh-rand-helper.
The HP-UX Strong Random Number Generator improves the performance and entropy
(a measure of the randomness and therefore the security of generated keys) of HP-UX
Secure Shell. It generates nonreproducible, true random numbers. The use of the HP-UX
Strong Random Number Generator is highly recommended with HP-UX Secure Shell.
The HP-UX Strong Random Number Generator is available by default. For more
information, see random(7).
4.6.10 TCP Wrappers Support
The HP-UX Secure Shell daemon, sshd, is linked with the archive library, libwrap.a,
to support TCP Wrappers. See also Section 4.3.
4.6 Securing Remote Sessions Using HP-UX Secure Shell (SSH) 83
4.6.11 chroot Directory Jail
chroot is a directory jail. It starts up an application in a specified directory and restricts
users to accessing that directory and the directories below it. It prevents users from
changing directories above that specified directory. It is intended to restrict file and
directory access to users of that application while they are using the application.
You must enable chroot for an application. You must create new directories and copy
the relevant set of files into those newly created directories.
You can optionally set up ssh, scp, and sftp with a chroot directory.
The HP-UX Secure Shell README file in /opt/ssh/README.hp explains the chroot
feature, the chroot setup script, and the specific files that this script copies to enable
ssh, sftp, and scp for a chroot environment. Refer also to chroot(1M).
The chroot setup script is in the /opt/ssh/utils/ssh_chroot_setup.sh file,
which is part of the HP-UX Secure Shell software product (Secure Shell 4.30.004/005).
84 Remote Access Security Administration
Part II Protecting Data
HP-UX 11i offers data protection in many forms: protecting data in transit, in use, and at rest.
By using security features designed to protect data in its three forms, HP-UX 11i customers can
minimize possible breaches not only in terms of data loss, but in customer trust as well.
This section describes the following topics:
• File system security (Chapter 5)
• Compartments (Chapter 6)
• Fine-grained privileges (Chapter 7)
85
86
5 File System Security
This chapter explains file system security. Before you read this chapter, you should have
a basic understanding of files and file systems.
Because data is stored in files, it is important to understand how to protect them. This
chapter discusses the following topics:
• Controlling file access (Section 5.1)
• Setting access control lists (Section 5.2)
• Using HFS ACLs (Section 5.3)
• Using JFS ACLs (Section 5.4)
• Comparison of JFS and HFS ACLs (Section 5.5)
• ACLs and NFS (Section 5.6)
• Security considerations for /dev devices special files (Section 5.7)
• Protecting disk partitions and logical volumes (Section 5.8)
• Security guidelines for mounting and unmounting file systems (Section 5.9)
• Controlling file security on a network (Section 5.10)
5.1 Controlling File Access
Working groups, file permissions, file ownership, and compartment rules determine who
can access a given file. The simplest of the file access rules are standard UNIX file
permissions.
You can divide users into groups so that files owned by the group can be shared within
the group and can be protected from outsiders.
The traditional UNIX file permissions are displayed using the ls command with the -l
flag. The permissions indicate what kind of access (that is, the ability to read, write, and
execute) is granted to the owner and groups on your system. Traditional UNIX file
protections allow some control over who can access your files and directories, but they
do not allow you to define access for individual users and groups beyond the owning
user and the owning group. The following is a brief review of UNIX file permissions.
Each file and each directory has nine permissions associated with it. Files and directories
have the following three types of permissions:
• r (read)
• w (write)
• x (execute)
These three permissions occur for each of the following three classes of users:
• u (user/owner)
• g (group)
• o (all others; also known as world)
5.1 Controlling File Access 87
The r permission allows users to view or print the file. The w permission allows users to
permission
owner group others
rwx rwx rwx
r read
w write
x execute
write (modify) the file. The x permission allows users to execute (run) the file or to search
directories.
Figure 5-1 shows the traditional permissions fields.
Figure 5-1 File and Directory Permission Fields
The user/owner of a file or directory is generally the person who created it. If you are
the owner of a file, you can change the file permissions with the chmod command.
The group specifies the group to which the file belongs. If you are the owner of a file,
you can change the group ID of the file with the chgrp command.
The meanings of the three types of permissions differ slightly between ordinary files and
directories. See Table 5-1 for more information.
Table 5-1 Differences Between File and Directory Privileges
r (read)
w (write)
5.1.1 Setting File Access Permissions
88 File System Security
The chmod command changes the type of access (read, write, and execute privileges)
for the file's owner, group members, or all others. Only the owner of a file or a user with
the appropriate privileges can change file access. See chmod(1).
Contents can be viewed or
printed.
deleted.
DirectoryFilePermission
Contents can be read, but not
searched. Normally r and x are
used together.
Entries can be added or removed.Contents can be changed or
Directory can be searched.File can be used as a program.x (execute)
By default, the initial set of read and write permissions for files and directories are
determined by the creator's umask value. To change the default file permissions, use
the umask command. See umask(1).
Each bit that is set in the file mode creation mask causes the corresponding permission
bit in the file mode to be cleared (disabled). Conversely, bits that are clear in the mask
allow the corresponding file mode bits to be enabled in newly created files.
For example, a umask of octal 022 creates a mask of u=rwx, g=rx, o=rx, which
disables group and other write permissions.
5.1.2 Setting File Ownership
The chown command changes file ownership. To change the owner, you must own the
file or have the appropriate privileges.
The chgrp command changes file group ownership. To change the group, you must
own the file or have the appropriate privileges.
For more information, see chown(1) and chgrp(1).
5.1.3 Protecting Directories
Normally, if a directory is writable either through standard permissions or through ACLs,
anyone can remove the files in the directory, regardless of the permissions on the files
themselves. To protect against unwanted file deletions in a directory:
• Remove write permissions for directories that should not have them.
This is particularly effective for users' private directories. The following command
allows others to read and search the mydir directory, but only the owner can delete
files from it:
# chmod 755 mydir
See chmod(1) and chmod(2).
• Set the sticky bit on the directory.
• The sticky bit is a special bit in the mode of every file. Setting the sticky bit prevents
users from removing other users' files from that directory. Setting the sticky bit for a
directory allows only the owner of the file, the owner of the directory, or a user with
the appropriate privileges to delete or to rename the files.
This is effective for temporary or project directories (such as /tmp and /var/tmp)
that must be accessible to many authorized users. The following command allows
anyone to create, read, and write files in /mfgproj, but only the file owner, the
directory owner, or a user with the appropriate privileges can delete files:
# chmod a+rwxt /mfgproj
Setting the sticky bit is important for directories that are used for temporary files. In
the event that a temporary directory is not set to sticky, an attacker may alter the
expected behavior of user programs by waiting for a temporary file to be created
5.1 Controlling File Access 89
and then deleting and recreating a new file with modified content, but the same
name. In most cases, the application is unaware of the change and may
unintentionally perform malicious acts on behalf of the attacker.
5.1.4 Protecting Files Related to User Accounts
Follow these guidelines to protect files related to user accounts:
• A home directory should not be writable by anyone except for the owner. Otherwise,
any user can add and remove files from the directory.
• The .profile, .kshrc, .login, and .cshrc files for each user should not be
writable by anyone other than the account owner.
• A user's .rhosts file should not be readable or writable by anybody other than
the owner. This precaution prevents users from guessing what other accounts you
have, and prevents anyone from editing your .rhosts file to gain access to those
systems. For more information, see hosts.equiv(4).
• Do not use a .netrc file, because it bypasses login authentication for remote
login and even contains the user's unencrypted password. If used, .netrc must
not be readable or writable by anyone other than its owner. For more information,
see netrc(4).
5.1.5 Locating and Correcting File Corruption Using fsck
The following problems can indicate a corrupt file system:
• A file contains incorrect data (garbage).
• A file has been truncated or is missing data.
• Files disappear or change locations unexpectedly.
• Error messages appear on a user's terminal, the system console, or in the system
log.
• You are not able to change directories or list files.
• The system fails to reboot.
If you or other users cannot readily identify problems with the file system, use the fsck
command to check the file system. The fsck command is the primary tool for finding
and correcting file system inconsistencies. The fsck command examines the file system
listed in /etc/fstab.
The fsck utility is not capable of detecting file corruption. If fsck does not find any
errors, the problem is likely not a corrupted file system. That is, the file system is usable,
even if the underlying data is lost or corrupted. Look for one or more of these other file
problems:
• A user, program, or application deleted, overwrote, moved, or truncated the file or
files.
• The file system associated with a particular directory when the file was created might
not be mounted to that directory.
90 File System Security
• A file or files were placed in a directory that now has a file system mounted to it.
The files still exist but are not accessible. Unmount the file system to access the files.
• The file protection or ownership is preventing access. Use the chmod or chown
command to change file permissions.
5.2 Setting Access Control Lists
Access control lists (ACLs) offer a finer degree of file protection than traditional file access
permissions. Use ACLs to allow or restrict file access to individual users unrelated to the
group they belong to. Only the owner of a file, or a user with the appropriate privileges
can create ACLs.
Both the Journaled File System (JFS) and High-Performance File System (HFS) support
ACLs but they use different mechanisms and syntax.
JFS is the HP-UX implementation of the Veritas journaled file system (VxFS). HFS is the
HP-UX version of the UNIX File System (UFS) and is compatible with earlier versions of
HP-UX.
An access control list (ACL) is a set of user, group, and mode entries associated with a
file. The list specifies permissions for all possible user ID and group ID combinations.
Access control lists give you a more precise way to control access to files than you have
with traditional UNIX file permissions. ACLs enable you to grant or restrict file access in
terms of individual users and specific groups, in addition to the traditional control.
Both HFS and JFS file systems support ACLs, but they use different mechanisms and use
different syntax.
NOTE: HFS is now deprecated. It will be removed from the operating system in a future
release.
HP-UX supports two separate JFS products: the basic JFS product, which is included in
the operating system, and the optional advanced product, OnLineJFS, which is installed
separately. Both JFS products support ACLs.
For more information, see setacl(1), getacl(1), aclv(5), chacl(1), lsacl(1), and acl(5).
5.3 Using HFS ACLs
You set HFS ACL permissions with the chacl command and display them with the lsacl
command. See Example 5-1.
5.2 Setting Access Control Lists 91
IMPORTANT: You must use chmod with the -A option when working with files that
have HFS ACL permissions assigned. Without the -A option, chmod will delete the ACL
permissions from the file. The syntax is:
# chmod -A mode file
The chacl command is a superset of the chmod command. Any specific permissions
you assign with the chacl command are added to the more general permissions assigned
with the chmod command.
When a file has ACLs, the ll command displays a plus sign (+) after the permission
string.
If a user.group matches more than one HFS ACL entry, the more specific entry takes
precedence. See Example 5-2.
92 File System Security
Example 5-1 Creating an HFS ACL
In this example, the chmod command restricts write permissions for myfile to only the
user, allan. The chmod command also deletes any previous HFS ACLs.
$ chmod 644 myfile
$ ll myfile
-rw-r--r-- 1 allan users 0 Sep 21 16:56 myfile
$ lsacl myfile
(allan.%,rw-)(%.users,r--)(%.%,r--) myfile
The lsacl command displays just the default (no ACL) values, corresponding to the
basic owner, group, and other permissions.
The chacl command gives read and write access to myfile to another user.
$ chacl 'naomi.users=rw' myfile
$ ll myfile
-rw-r--r--+ 1 allan users 0 Sep 21 16:56 myfile
$ lsacl myfile
(naomi.users,rw-)(allan.%,rw-)(%.users,r--)(%.%,r--) myfile
Notice two things: the ll permissions display has a + appended, indicating that ACLs
exist and that the ll permissions string did not change. The additional entry in the lsacl
display specifies that user naomi in group users has read and write access to myfile.
Example 5-2 Multiple HFS ACL Matches
If a user's user.group combination matches more than one ACL entry, the most specific
entry takes precedence. In this example, first set the file permissions.
$ chmod 644 myfile
Use the chacl command on myfile to add a write-only entry for user naomi:
$ chacl naomi.%=w myfile
$ lsacl myfile
(naomi.%,-w-)(allan.%,rw-)(%.users,r--)(%.%,r--) myfile
Now, user naomi has write access to file myfile, using the ACL defined for naomi.%,
but does not have read access to the file because naomi.% takes precedence over the
ACLs defined for %.users and %.%.
The lsaclcommand displays the HFS ACLs in decreasing order of specificity. That is,
permission matches are attempted from left to right.
5.3.1 HFS ACLs and HP-UX Commands and Calls
The following commands and system calls work with ACLs on HFS file systems:
5.3 Using HFS ACLs 93
Table 5-2 HFS ACL Commands
Table 5-3 HFS ACL System Calls
DescriptionCommands
Changes HFS ACLs of files.chacl
Lists user's access rights to files.getaccess
Lists HFS ACLs of files.lsacl
DescriptionSystem Call
Gets a user's effective access rights to a file.getaccess
Gets HFS ACL information.getacl, fgetacl
Sets HFS ACL information.setacl, fsetacl
Converts HFS ACL structure to string form.acltostr
chownacl
cpacl, fcpacl
strtoaclpatt
Changes the owner or group represented in an HFS
file's ACL.
Copies HFS ACL and mode bits from one file to
another.
Adds, modifies, or deletes an HFS file's ACL entry.setaclentry, fsetaclentry
Parses and converts HFS ACL structure to string form.strtoacl
Parses and converts HFS ACL pattern strings to
arrays.
The following commands, system calls, and subroutine libraries affect ACL entries,
sometimes in unexpected ways.
Table 5-4 Commands and Calls Affecting ACL Entries
DescriptionCommand or Call
chmod
chmod
find
Deletes HFS ACLs by default. Use the -A option to
retain HFS ACLs.
Deletes HFS ACL entries. Use getacl and setacl
to save and restore the HFS ACL entries.
Does not set a file's optional ACL entries.cpset
Identifies files whose ACL entries match or include
specific ACL patterns on HFS or JFS file systems.
ls -l
94 File System Security
The long form indicates the existence of ACLs by
displaying a plus sign (+) after the file's permission
bits.
Table 5-4 Commands and Calls Affecting ACL Entries (continued)
DescriptionCommand or Call
mailx
frecover, fbackup
ar, cpio, ftio, shar, tar, dump, restore
HFS access control lists use additional “continuation inodes” when creating new file
systems. Consider them when using the following commands:
• fsck: Returns the number of files with ACL entries as a value for icont. Use the
-p option to clear unreferenced continuation inodes. See fsck(1M).
• diskusg, ncheck: Ignores continuation inodes. See diskusg(1M) and ncheck(1M).
• mkfs: Allows for continuation inodes on new disks. See mkfs(1M).
5.4 Using JFS ACLs
This section describes JFS ACLs and how to use them.
Does not support optional ACL entries on /var/
mail/* files.
Copies ACL entries to the new files they create.compact, compress, cp, ed, pack, unpack
Use only these commands to selectively recover and
back up files. Use the -A option when backing up
from an ACL system for recovery on a system that
does not support ACLs.
These commands do not retain ACLs when archiving
and restoring. They use the st_mode value returned
by stat.
These commands do not support ACLs.rcs, sccs
NOTE: To use JFS ACLs, you must have a VxFS file system using disk layout Version
4. See vxupgrade(1M) for information about upgrading the file system to Version 4.
5.4.1 Definition of a JFS ACL
A JFS ACL contains one-line entries naming specific users and groups and indicating
what access is granted to each. The presence of a JFS ACL also changes the meaning
of the group permission bits, which are displayed using the ls -l command.
A JFS ACL always has at least four entries: a user entry, a group entry, a class entry,
and an other entry. When a JFS ACL contains only these four entries, the permissions
it grants are exactly the same as the permissions represented by the standard UNIX
system permission bits.
5.4.2 How the System Generates a JFS ACL
Whenever a file is created on a JFS file system, the system initializes a minimal JFS ACL
for the file, containing a user entry for the owner permissions, a group entry for the
owning group permissions, a class entry for the owning group permissions, and an
5.4 Using JFS ACLs 95
other entry for the other group permissions. Additional entries can be added by the
user, or as a result of default entries specified on the parent directory.
5.4.3 Minimal JFS ACL
An ACL with the four basic entries defined previously is called a minimal JFS ACL. An
example minimal ACL looks like this:
user::rwgroup::r-class:r-other:---
• The user entry indicates the permissions of the owner of the file and maps directly
to the owner permission bits. Because the first entry applies to the owner of the file,
no user name needs to be indicated. This example ACL entry grants read and write
access to the file's owner.
• The group and class entries specify the permission granted to members of the
file's owning group. The example ACL entry grants read-only access to the file's
owning group. The group and class entries are described more in Section 5.4.5.
• The other entry is a catch-all entry that specifies permissions for anyone who is
not granted or denied permission by any other entry. The example other entry
denies access to all users who are not the owner of the file nor in the file's owning
group.
The permission bits displayed by ls -l for this file would look like this:
rw-r-----
The next section describes how additional JFS ACL entries affect file access and the
interpretation of the permission bits.
5.4.4 Additional JFS ACL user and group Entries
If you want to grant or deny access to specific users and groups on the system, you can
add up to 13 more user and group entries to the four minimal entries described in the
previous section.
For example, the following entry in the ACL of a file grants read, write, and execute
access to a user logged in as boss:
user:boss:rwx
In the next example, an ACL with the following entry denies access to a user in the group
spies:
group:spies:---
5.4.5 JFS ACL group and class Entries
In a file with a minimal ACL, the owning group and class ACL entries are identical.
However, in a file with additional entries, the owning group and class ACL entries
96 File System Security
are distinct. The owning group entry grants permissions to a specific group: the owning
group.
The class entry is more general; it specifies the maximum permissions that can be
granted by any of the additional user and group entries.
If a particular permission is not granted in the class entry, it cannot be granted by any
ACL entries except for the first user (owner) entry and the other entry. Any permission
can be denied to a particular user or group. The class entry functions as an upper
bound for file permissions.
When an ACL contains more than one group or user entry, the additional user and
group entries are referred to as the group class entries, because the effective
permission granted by any of these additional entries is limited by the class entry.
5.4.6 Using the setacl and getacl Commands
Use the setacl and getacl commands to change and view ACLs.
Use the setacl command to change the ACL in one of the following ways:
• Replace a file's entire ACL, including the default ACL on a directory.
• Add, modify, or delete one or more entries, including default entries on directories.
The getacl command displays the entries in the ACL. File permission bits for user and
group are translated into special cases of these entries:
• The bits representing owner permissions are represented by a user entry without
a specified user ID.
• The bits representing group permissions are represented by a group entry without
a specified group ID.
An ACL must contain one each of these special user and group entries. The ACL
can have any number of additional user entries and group entries, but these must
all contain a user ID or group ID, respectively. An ACL has only one other entry,
representing the permission bits for permissions to be granted to other users.
See setacl(1) and getacl(1) for command descriptions.
5.4.7 Effect of chmod on class Entries
When a file has a minimal ACL, the owning group and class ACL entries are identical,
and chmod affects both of them. However, when a file contains additional, optional
entries in the ACL, the following consequences occur:
• The class ACL entry no longer necessarily equals the owning group ACL entry.
• The chmod command affects the class ACL entry, not the owning group entry.
• You must use the setacl command to change the owning group entry.
5.4 Using JFS ACLs 97
5.4.8 Example of Changing a Minimal JFS ACL
To illustrate the function of the JFS ACL class entry, this section describes how chmod
and setacl affect a file with a minimal JFS ACL and a file with group class entries.
NOTE: Further details about the use of the getacl and setacl commands are in
Section 5.4.10. Refer also to getacl(1) and setacl(1).
Consider a file, exfile, with read-only (444) permissions and a minimal JFS ACL. The
ls -l command shows the permissions for exfile:
$ ls -l exfile
-r--r--r-- 1 jsmith users 12 Sep 20 15:02 exfile
The getacl command lists the following output for exfile, which is a minimal JFS
ACL:
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::r-group::r-class:r-other:r--
Using the chmod command to add write permissions to exfile changes both the owning
group and the class ACL entries. For example, look at the getacl command output:
$ chmod 666 exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rwgroup::rwclass:rwother:rw-
Now add additional user and group entries, that will affect the class ACL entry but not
the owning group entry. The first setacl command that follows grants read-only
permission to user guest; the other ACL entries are unaffected. However, the second
setacl command grants read-execute permissions to the group dev, and the upper
bound on permissions (the class entry) is extended to include execute permission.
$ setacl -m u:guest:r-- exfile
$ setacl -m g:dev:r-x exfile
$ getacl exfile# file: exfile
# owner: jsmith
# group: users
user::rwuser:guest:r-group::rw-
98 File System Security
group:dev:r-x
class:rwx
other:rw-
Next, the chmod command removes write and execute permission from group, and
actually reduces the class permissions to read-only. The owning group permissions,
while unchanged, are effectively reduced to read-only as well.
$ chmod g-wx exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rwuser:guest:r-group::rw- # effective:r-group:dev:r-x # effective:r-class:r-other:rw-
The other permissions are unchanged. The class entry does not limit the access that
can be granted by the first user (owner) entry or the other entry.
Next the ls -l command lists the permissions of exfile. The plus sign (+) at the end
of the permissions string indicates that there is an ACL for the file.
$ ls -l exfile
-rw-r--rw-+ 1 jsmith users 12 Sep 20 15:02 exfile
5.4.9 Default JFS ACLs
You might want all the files created in a directory to have certain ACL entries. For
example, you can allow another person to write to any file in a directory of yours when
the two of you are working on something together.
You can put an ACL entry granting the desired access on every file in the directory, but
every time you create a new file, you have to add that entry again. Using default ACL
entries, you can get the system to do this for you automatically every time you create a
file.
A default ACL entry appears as follows:
default:user:boss:rw-
Default ACLs can only be placed only on a directory and have no influence on what
access to the directory is granted to a user. The default ACL is applied to files created
in the directory.
When the newly created file is a directory, the default ACL entries have two effects:
• The corresponding nondefault ACL entries are created, so that the desired permissions
are granted and denied for the directory, just as for any file created in the directory.
• The default entries themselves are copied, so that the new subdirectory has the same
default ACL as the parent directory.
5.4 Using JFS ACLs 99
For example, if you want any files created in the directory projectdir to be readable
by certain users, you can create the appropriate default entries, as follows:
$ setacl -m d:u:boss:r,d:u:jjones:r,d:u:dev:r projectdir
$ getacl projectdir
# file: projectdir
# owner: jsmith
# group: users
user::rwuser:boss:rwuser:jjones:rwuser:jdoe:--group::rwgroup:dev:rwclass:rwother:--default:user:boss:r--default:user:jjones:r-default:group:dev:r--
If the newly created file is a directory, the same ACL entries are generated. In addition,
the default entries themselves are also placed in the ACL.
With these entries in place, any new file created in the directory projectdir will have
an ACL like that shown previously without the default entries.
5.4.10 Changing JFS ACL with the setacl Command
This section presents more examples of using the setacl command.
5.4.10.1 Using the Modify and Delete Options
The following setacl command uses the -m (modify) option to give read-only access
to the user boss for the junk file:
$ setacl -m u:boss:r-- junk
To grant read and write access to everyone in the group dev, use the group (g:)
parameter with the setacl -m command:
$ setacl -m g:dev:rw- junk
The -d option deletes an entry. With -d, do not specify any permissions in the ACL
entry. For example, the following command deletes the entry for the group dev:
$ setacl -d g:dev junk
5.4.10.2 Using the -f Option
If you are adding or changing several entries, you can use a different procedure. You
can save the ACL to a file, edit the file, and then apply this new ACL to the file. For
example, save the ACL to a file with this command:
$ getacl junk > junk.acl
100 File System Security
Loading...