IBM Tivoli Access Manager for Operating Systems. Administration Guide. Version 5.1 SC

Transcription

1 IBM Tioli Access Manager for Operating Systems Administration Guide Version 5.1 SC

2

3 IBM Tioli Access Manager for Operating Systems Administration Guide Version 5.1 SC

4 Note Before using this information and the product it supports, read the information in Appendix E, Notices, on page 317. First Edition (Noember 2003) This edition applies to ersion 5, release 1, of IBM Tioli Access Manager for Operating Systems (product number 5698-PDO) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation 2000, All rights resered. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Tables ii Preface ix Who should read this guide ix What this guide contains ix Publications x Tioli Access Manager for Operating Systems library x Prerequisite publications xi Related publications xi Platform-specific information xii Accessing publications online xii Accessibility xii Contacting software support xii Conentions used in this guide xiii Chapter 1. Introduction Enironment Authorization model The UNIX identity and its relationship to the Tioli Access Manager user identity Authorization policy Chapter 2. Policy Policy administration Protected object name structure Namespace root Policy branch Resource types Object name Wildcards Access controls Access control lists Access restrictions Inheritance and traersal Protected object policies POP attributes used for access control Protected system resources File policy Network policy Network resource access control Login policy Password management policy Surrogate policy Sudo Policy The pdossudo command Audit resources Audit authorization resources Audit trace resources Chapter 3. Runtime Daemons The pdosd authorization daemon The pdosauditd audit daemon The pdoswdd watchdog daemon The pdostecd Tioli Enterprise Console daemon 81 Periodic log maintenance The pdoslpmd login policy and password management daemon The pdoslrd log router daemon Users and groups osseal-admin group osseal group osseal user root user osseal-auditors group ossaudit group osseal-unauth user pdosd-hostname user critical cred group Files and directories Initial policy osseal-audit osseal-audit-exec osseal-credentials osseal-default osseal-default-file osseal-default-login osseal-default-net-incoming osseal-default-net-outgoing osseal-default-sudo osseal-default-surrogate osseal-exec-open osseal-exec-root osseal-hla osseal-kazndr osseal-logs osseal-open osseal-priileged-user osseal-restricted osseal-restricted-read osseal-tcb osseal-umsg osseal-ar-lpm Isolated operation Isolation from the Tioli Access Manager policy serer Isolation from the Tioli Access Manager user registry Isolation from non-local UNIX user registry..94 Isolation from the hostname resolution serer..95 Chapter 4. The log router daemon Log router control file Log router control file example Log router control file elements XML header Serer element Router element Copyright IBM Corp. 2000, 2003 iii

6 Channel element Filters element Filter element Conditional element Field element Filter definitions Channels Channel types Using the channel types Log router audit record fields Supported fields Supported field alues Supported formats Field table Encoded field alues Log router output formats Local file output LRD_FileOutput output LRD_ Output Network output LRD_NetOutput File rolloer Output compression Chapter 5. Administratie tasks Defining runtime administrators and auditors..115 Establishing a consistent user name space Identifying users and groups Identifying duplicate user names Using pdosrgyimp Tuning the configuration Limiting ACL inheritance for network policy Obtaining the policy branch membership report 120 Managing processes Starting Tioli Access Manager for Operating Systems Stopping Tioli Access Manager for Operating Systems Checking daemon status Daemon log files Verifying policy Using warning mode to erify policy Using auditing to erify policy Managing the Trusted Computing Base Tuning the pdosd daemon s Trusted Computing Base monitoring Managing the object signature database Managing scheduled upgrades to files registered in the Trusted Computing Base Managing operating system upgrades Managing login actiity and password management policy enforcement Viewing account records Locking and unlocking accounts Password change date for user accounts Creation of local user accounts with minimum password age policy Configuring NIS for login actiity policy Managing credentials Tuning the credentials cache Explicitly refreshing credentials Explicitly destroying credentials Determining the accessor identity i IBM Tioli Access Manager for Operating Systems: Administration Guide Examples of pdoswhoami and pdoswhois Configuring and managing the hostname look-aside database Configuring the database Managing the database Backing up and restoring configuration files and databases Backing up configuration files and databases 137 Restoring Tioli Access Manager for Operating Systems Chapter 6. Tasks aailable from Tioli Desktop Task oeriew General information regarding wrunjob and wruntask Add/Remoe PDOS Auditors/Administrators Syntax for wrunjob and wruntask Backup PDOS Database Syntax for wrunjob and wruntask Certificate Transfer Utility Syntax for wrunjob and wruntask Configure PDOS Auditing Syntax for wrunjob and wruntask Configure PDOS Caching Syntax for wrunjob and wruntask Configure PDOS Logging Syntax for wrunjob and wruntask Configure PDOS Login and Password Policy Syntax for wrunjob and wruntask Configure PDOS Serer Syntax for wrunjob and wruntask Configure PDOS TCB Syntax for wrunjob and wruntask Display PDOS Hostname Cache Syntax for wrunjob and wruntask Distribute Log Router Daemon Control File Syntax for wrunjob and wruntask Import UNIX TCB Syntax for wrunjob and wruntask Import UNIX Users and Groups Syntax for wrunjob and wruntask Manage PDOS Credential Cache Syntax for wrunjob and wruntask Manage PDOS Serer State Syntax for wrunjob and wruntask Manage PDOS TCB Syntax for wrunjob and wruntask Purge PDOS Hostname Cache Syntax for wrunjob and wruntask Query Branch Membership Syntax for wrunjob and wruntask Query PDOS Login and Password Policy Syntax for wrunjob and wruntask Query PDOS Serer State Syntax for wrunjob and wruntask Query PDOS TCB Syntax for wrunjob and wruntask Restore PDOS Database Syntax for wrunjob and wruntask Set PDOS Serer Audit Leel

7 Syntax for wrunjob and wruntask Set PDOS Serer Trace Leel Syntax for wrunjob and wruntask Setup TEC Eent Serer for PDOS Syntax for wrunjob and wruntask Show PDOS Auditing Configuration Syntax for wrunjob and wruntask Show PDOS Auditors/Administrators Syntax for wrunjob and wruntask Show PDOS Caching Configuration Syntax for wrunjob and wruntask Show PDOS Logging Configuration Syntax for wrunjob and wruntask Show PDOS Serer Audit Leel Syntax for wrunjob and wruntask Show PDOS Serer Configuration Syntax for wrunjob and wruntask Show PDOS TCB Configuration Syntax for wrunjob and wruntask Start PDOS TEC Adapter Syntax for wrunjob and wruntask Stop PDOS TEC Adapter Syntax for wrunjob and wruntask Subscribe PDOS Endpoints Syntax for wrunjob and wruntask Update PDOS Hostname Cache Syntax for wrunjob and wruntask Chapter 7. Auditing Auditing authorization decisions Auditing administratie actiity Auditing trace eents Enabling auditing Global auditing Resource-leel auditing User-leel audit Setting and querying the user audit leels Warning mode Enabling, disabling, and querying global warning mode Enabling, disabling, and querying resource warning mode The audit log file Audit log consolidation Viewing audit logs Concise format Keyalue format Verbose format Audit log record types General audit eent record type Trace audit eent record type Logout audit eent record type Effectiely using the audit iew tool Sample searches Chapter 8. Commands pdosaudiew pdosbkup pdoscfg pdoscolliew pdosctl pdosdestroy pdosexempt pdoshla pdoslpadm pdoslradm pdosobjsig pdosrefresh pdosreoke pdosrgyimp pdosrstr pdosshowuser pdossudo pdosteccfg pdostecucfg pdosucfg pdosuidprog pdosunauth pdosersion pdoswhoami pdoswhois policyiew Chapter 9. Integrating with Tioli Enterprise Console Oeriew Installing and configuring the logfile adapter Chapter 10. Integrating with IBM Tioli Risk Manager Oeriew Installing and configuring the logfile adapter to integrate with Tioli Risk Manager Integrating with IBM Tioli Enterprise Data Warehouse Appendix A. Policy quick reference 291 Appendix B. Wildcard character set expressions Appendix C. Tioli Enterprise Console and Tioli Risk Manager eents Tioli Enterprise Console Eents Tioli Risk Manager Eents Appendix D. Accessibility Appendix E. Notices Trademarks Index Contents

8 i IBM Tioli Access Manager for Operating Systems: Administration Guide

9 Tables 1. Wildcard Elements Wildcard Matching Examples Wildcard Element Precedence Rules Wildcard Pattern Precedence Examples Permissions Defined in the OSSEAL Action Group Tioli Access Manager Primary Actions Used for Policy Management Tioli Access Manager Primary Actions Used for Policy Decisions File System Objects File Permissions Login Programs Certified for IBM Tioli Access Manager for Operating Systems System Programs Defined as Immune-Programs in Default Policy Network Resource Naming Valid Permission for Incoming or Outgoing Connection to a Network Resource Definitions of Terms about Terminals Valid Permission to Log In Login Actiity Policy Attributes Password Management Policy Attributes Surrogate Object Naming Surrogate Operation Permission Sudo Objects Sudo Command Attributes Permission Required for Sudo Extended Sudo Attributes for Fine-grained Control Enironment Variables Stripped by Sudo Enironment Variables Set by Sudo User-leel audit authorization objects User-leel audit trace objects Tioli Access Manager for Operating Systems Credential Configuration Attributes Configuration Attributes Controlling pdosd s Communications with the User Registry Authorization Configuration Attributes Authorization Policy-branch Configuration Attribute pdosd TCB File Monitoring Resource Configuration Attributes pdosd Log Configuration Attributes Global Audit-Leel Configuration Attribute pdosauditd Configuration Attributes pdoswdd Configuration Attributes pdostecd Configuration Attributes pdoslpmd Configuration Attribute pdoslrd Configuration Attributes Attribute Equialents of pdoscfg Options in osseal.conf Attribute Equialents of pdoscfg Options for pdosd.conf Attribute Equialents of pdoscfg Options in pdosauditd.conf Attribute Equialents of pdoscfg Options in pdoswdd.conf Attribute Equialents of pdoscfg Options in pdoslrd.conf pdoscfg Options that Control the Daemon Log Files Authorization for IBM Tioli Access Manager for Operating Systems Tasks Global Audit Leels General Audit Eent Record Type Description of Audit Eent Identifiers Description of Audit Qualifiers Trace Audit Eent Record Type Logout Audit Eent Record Type System Resources and Corresponding IBM Tioli Access Manager for Operating Systems Resource Types Tioli Access Manager for Operating Systems Permissions Defined in the [OSSEAL] Action Group Tioli Access Manager Primary Actions Used for Policy Management Tioli Access ManagerPrimary Actions Used for Policy Decisions Special Elements of Wildcard Character Set Wildcard Character Set Character Classes Valid for all Locales Process Related Tioli Enterprise Console Eents File-Related Tioli Enterprise Console Eents Network-Related Tioli Enterprise Console Eents Sudo-Related Tioli Enterprise Console Eents Set(User)-Related Tioli Enterprise Console Eents Set(Group)-Related Tioli Enterprise Console Eents TCB-Related Tioli Enterprise Console Eents Policy-Related Tioli Enterprise Console Eents Login-Related Tioli Enterprise Console Eents Credential-Related Tioli Enterprise Console Eents Password-Strength-Related Tioli Enterprise Console Eents Process-Related Tioli Risk Manager Eents File-Related Tioli Risk Manager Eents Network-Related Tioli Risk Manager Eents Sudo-Related Tioli Risk Manager Eents Set(User)-Related Tioli Risk Manager Eents Set(Group)-Related Tioli Risk Manager Eents TCB-Related Tioli Risk Manager Eents Policy-Related Tioli Risk Manager Eents 313 Copyright IBM Corp. 2000, 2003 ii

10 78. Login-Related Tioli Risk Manager Eents Credential-Related Tioli Risk Manager Eents Password-Strength-Related Tioli Risk Manager Eents iii IBM Tioli Access Manager for Operating Systems: Administration Guide

11 Preface Who should read this guide IBM Tioli Access Manager for Operating Systems is application software that proides a layer of authorization policy enforcement in addition to that proided by the natie operating system. Note: IBM Tioli Access Manager for Operating Systems is the new name for the product preiously released as Tioli SecureWay Policy Director for Operating Systems (Version 3.7) and Tioli Policy Director for Operating Systems (Version 3.8). Also, for users familiar with the Tioli SecureWay Policy Director software and documentation, the management serer is now referred to as the policy serer. The IBM Tioli Access Manager for Operating Systems Administration Guide describes how to use IBM Tioli Access Manager for Operating Systems and proides a reference of the aailable commands. This book is for administrators and system programmers who hae some knowledge of these topics: UNIX operating system Internet protocols, including HTTP, TCP/IP, FTP, Telnet, SSL Security management Authentication Authorization What this guide contains IBM Tioli Access Manager Base Lightweight Directory Access Protocol (LDAP) and directory serices Supplementary information that systems administrators may find useful includes knowledge of the following topics: IBM Tioli Management Enironment framework IBM Tioli Enterprise Console IBM Tioli Directory Serer (LDAP) IBM Tioli User Administration This book contains the following sections: Chapter 1, Introduction, on page 1 Proides an introduction to Tioli Access Manager for Operating Systems and its functions. Chapter 2, Policy, on page 5 Describes the resources Tioli Access Manager for Operating Systems proides protection for, helps you plan your protection requirements. Chapter 3, Runtime, on page 67 Copyright IBM Corp. 2000, 2003 ix

12 Describes the Tioli Access Manager for Operating Systems runtime components and their enironment. This chapter also describes the Tioli Access Manager for Operating Systems daemons. Chapter 4, The log router daemon, on page 97 Describes the audit log consolidation functionality proided through the Tioli Access Manager for Operating Systems log router daemon. Chapter 5, Administratie tasks, on page 115 Explains the administratie tasks required to manage Tioli Access Manager for Operating Systems. Chapter 6, Tasks aailable from Tioli Desktop, on page 139 Describes the management tasks proided to allow Tioli Access Manager for Operating Systems to be managed with the Tioli desktop. Chapter 7, Auditing, on page 191 Explains how to use the auditing functions to track access to protected functions and monitor actiity. Chapter 8, Commands, on page 219 Proides a reference to all the Tioli Access Manager for Operating Systems commands. It lists each command and its syntax, options, and usage. Chapter 9, Integrating with Tioli Enterprise Console, on page 283 Describes how Tioli Access Manager for Operating Systems can be integrated with the Tioli Enterprise Console. Chapter 10, Integrating with IBM Tioli Risk Manager, on page 287 Describes how Tioli Access Manager for Operating Systems can be integrated with Tioli Risk Manager. Appendix A, Policy quick reference, on page 291 Proides a quick reference to the policy resources and permissions. Appendix B, Wildcard character set expressions, on page 293 Lists and defines the wildcard character set expressions. Appendix C, Tioli Enterprise Console and Tioli Risk Manager eents, on page 295 Describes the eents sent to the Tioli Enterprise Console. Appendix D, Accessibility, on page 315IBM Tioli Access Manager Base Describes the accessibility that are proided to make Tioli Access Manager for Operating Systems aailable to users with physical disabilities. Publications Read the descriptions of the Tioli Access Manager for Operating Systems library, the prerequisite publications, and the related publications to determination which publications you might find helpful. After you determine the publications you need, refer to the instructions for accessing publications online. Tioli Access Manager for Operating Systems library The following documents are aailable in the Tioli Access Manager for Operating Systems library: IBM Tioli Access Manager for Operating Systems Administration Guide, SC Describes the concepts and procedures for using Tioli Access Manager for Operating Systems. Proides instructions for performing administratie tasks x IBM Tioli Access Manager for Operating Systems: Administration Guide

13 from the command line and from the Tioli Desktop, as well as auditing, using commands, and integrating with IBM Tioli Enterprise Console and IBM Tioli Risk Manager. IBM Tioli Access Manager for Operating Systems Installation Guide, SC Describes how to install, configure, upgrade, and uninstall Tioli Access Manager for Operating Systems. IBM Tioli Access Manager for Operating Systems Problem Determination Guide, SC Proides information about troubleshooting, message logging, trace logging, other diagnostic tools, and reference information about Tioli Access Manager for Operating Systems. Also contains the product error message catalog. IBM Tioli Access Manager for Operating Systems Release Notes, GI Proides late-breaking information about Tioli Access Manager for Operating Systems. IBM Tioli Access Manager for Operating Systems Read This First Card, GI Proides information for installing and getting started using Tioli Access Manager for Operating Systems. Prerequisite publications To use the information in this book effectiely, you must hae some prerequisite knowledge, which you can obtain from the following publications: IBM Tioli Access Manager Base Installation Guide, GC IBM Tioli Access Manager Base Administration Guide, GC IBM Tioli Access Manager for e-business Release Notes, GI Related publications Information related to Tioli Access Manager for Operating Systems is aailable in the following publications: IBM Tioli Access Manager for e-business Performance Tuning Guide, SC Proides performance tuning information for an enironment consisting of Tioli Access Manager with IBM Directory Serer defined as the user registry. IBM Tioli Access Manager for e-business Problem Determination Guide, SC Proides information about troubleshooting a Tioli Access Manager enironment. IBM Tioli Access Manager Error Message Reference, SC Contains the product error messages catalogs for IBM Tioli Access Manager, Tioli Access Manager for Operating Systems, and Tioli Access Manager Business Integration. IBM Tioli Access Manager for e-business Command Message Reference, SC Proides information about the Tioli Access Manager commands and their options. The Tioli Software Library proides a ariety of Tioli publications, such as white papers, datasheets, demonstrations, redbooks, and announcement letters. The Tioli Software Library is aailable on the Web at: The Tioli Glossary includes definitions for many of the technical terms related to Tioli software. The Tioli Glossary is aailable, in English only, at the following Web site: Preface xi

14 Accessibility Platform-specific information Information on supported platforms can be found in the IBM Tioli Access Manager for Operating Systems Installation Guide and the IBM Tioli Access Manager for Operating Systems Release Notes. Accessing publications online The publications for this product are aailable online in Portable Document Format (PDF) or Hypertext Markup Language (HTML) format, or both, in the Tioli Software Library: Contacting software support To locate product publications in the library, click the Product manuals link on the left side of the library page. Then, locate and click the name of the product on the Tioli software information center page. Product publications include release notes, installation guides, user s guides, administration guides, problem determination guides, and deeloper s references. Note: To ensure proper printing of PDF publications, select the Fit to page check box in the Adobe Acrobat Print (which is aailable when you click File Print). Accessibility features help a user who has a physical disability, such as restricted mobility or limited ision, to use software products successfully. With this product, you can use assistie technologies to hear and naigate the interface. You can also use the keyboard instead of the mouse to operate all features of the graphical user interface. For additional information, see Appendix D Accessibility. Before contacting IBM Tioli Software support about a problem, refer to the IBM Tioli Software support site by clicking the Tioli support link at the following Web site: If you need additional help, contact software support by using the methods described in the IBM Software Support Guide at the following Web site: The guide proides the following information: Registration and eligibility requirements for receiing support Telephone numbers, depending on the country in which you are located A list of information you should gather before contacting customer support. See the IBM Tioli Access Manager for Operating Systems Problem Determination Guide for additional direction about gathering information to be used for problem identification and remediation. xii IBM Tioli Access Manager for Operating Systems: Administration Guide

15 Conentions used in this guide This book uses seeral conentions for special terms and actions, operating system-dependent commands and paths, and margin graphics. This guide uses the following IBM-style typeface conentions: Bold Italics Monospace Lowercase and mixed-case commands, command options, and flags that appear within text are displayed like this, in bold type. Graphical user interface elements (except for titles of windows and dialogs) and names of keys are also displayed like this, in bold type. Variables, alues you must proide, new terms, and words and phrases that are emphasized are displayed like this, in italic type. Commands, command options, and flags that appear on a separate line, code examples, output, and message text are displayed like this, in a monospace font. Names of files and directories, text strings you must type, when they appear within text, names of Jaa methods and classes, and HTML and XML tags also are displayed like this, in a monospace font. Preface xiii

16 xi IBM Tioli Access Manager for Operating Systems: Administration Guide

17 Chapter 1. Introduction Welcome to the IBM Tioli Access Manager for Operating Systems Administration Guide. This guide contains detailed information about Tioli Access Manager for Operating Systems and describes the enironment, authorization model, and the commands proided. This chapter proides an oeriew of the product and describes the enironment so that you are better equipped to plan for and enforce authorization policy on your systems. Tioli Access Manager for Operating Systems proides a layer of authorization policy enforcement in addition to that proided by the natie operating system. An administrator defines additional authorization policy by applying fine-grained access controls that restrict or permit access to key system resources. Controls are based on user identity, group membership, the type of operation, time of the day or day of the week, and the accessing application. An administrator can control access to specific file resources, login and network serices, and changes of identity. These controls can also be used to manage the execution of administratie procedures and to limit administratie capabilities on a per-user basis. In addition to authorization policy enforcement, mechanisms are proided to erify defined policy and audit authorization decisions. Access controls are stored in a policy database that is centrally maintained in the IBM Tioli Access Manager enironment. The accessing user definitions are stored in a user registry that is also centrally maintained in the enironment. When protected resources are accessed, Tioli Access Manager for Operating Systems performs an authorization check based on the accessing user s identity, the action, and the resource s access controls to determine if access should be permitted or denied. Enironment Tioli Access Manager for Operating Systems functions in a Tioli Access Manager enironment, as shown in Figure 1 on page 2. Copyright IBM Corp. 2000,

18 Tioli Access Manager Policy Serer Tioli Access Manager Policy Database LDAP Serer User Registry User Mode User Request Kernel Mode Tioli Access Manager for Operating Systems Processes Replicated Tioli Access Manager Database Credential Cache Tioli Access Manager for Operating Systems Kernel Interception Natie Operating System Serices Figure 1. An Oeriew of IBM Tioli Access Manager for Operating Systems Tioli Access Manager is a network-based authorization framework that proides a backbone for defining, managing, and enforcing authorization policy. Multiple resource managers can use this framework. Tioli Access Manager for Operating Systems is one of the resource managers that use the authorization serice proided by Tioli Access Manager. Other resource managers include IBM Tioli Access Manager WebSEAL and IBM Tioli Access Manager for Business Integration. Tioli Access Manager is administered through a central serer that all resource managers can access. This lets an administrator control policy for a large number of similar machines from one central location. Tioli Access Manager for Operating Systems is installed on each machine that you want to protect. The Tioli Access Manager enironment includes two main databases used by the resource managers. The first database, the Tioli Access Manager user registry, stores the user and group definitions and is used for managing and identifying users in the Tioli Access Manager enironment. The Tioli Access Manager enironment must be set up to use an LDAP user registry. The second database, the Tioli Policy Database, stores all of the policy defined for each of the resource managers to enforce security. The policy database is where the access controls are stored. Resource managers access these two databases oer a network using TCP, secured by Secure Socket Layers (SSL). In addition to the databases, Tioli Access Manager proides a standardized authorization API by which all authorization decisions are made. Although Tioli Access Manager for Operating Systems relies on the information stored in the centrally maintained Tioli Access Manager databases, the information required to make authorization decisions is replicated and cached to enable authorization policy to continue to be enforced een if the Tioli Access 2 IBM Tioli Access Manager for Operating Systems: Administration Guide

19 Authorization model Manager policy serer or the Tioli Access Manager user registry serer becomes inaccessible. See Chapter 3, Runtime, on page 67 for a discussion of these topics. Tioli Access Manager for Operating Systems components operate in the user-leel application space and also within the UNIX kernel. The Tioli Access Manager for Operating Systems kernel extension and user-leel components interact in a tightly integrated secure manner to proide an extended layer of authorization enforcement. Applications access system resources through system-proided APIs, which eentually arrie in the UNIX kernel through a ariety of mechanisms. On a system not protected by Tioli Access Manager for Operating Systems, the natie system s security erifies whether the accessing user s natie identity has the authorization to perform the requested action and either carries out the operation or denies it. The primary function of the kernel extension is to interene in accesses to resources that are subject to the authorization policy. The kernel extension uses the authorization daemon process, PDOSD, to obtain an authorization decision and then enforces that decision. If the policy permits access to the resource, the operation continues and is then subject to the natie system s security. Otherwise the resource access is denied. The PDOSD daemon maps UNIX user identities to Tioli Access Manager credentials that describe users and their group memberships from a Tioli Access Manager point of iew. The PDOSD daemon then utilizes the Tioli Access Manager Authorization API to obtain authorization decisions based on the credentials, the operation being performed, the resource being accessed, and its associated access controls defined in the policy database. The UNIX identity and its relationship to the Tioli Access Manager user identity To acquire the credentials needed to make an authorization decision, the accessing user s natie numerical UNIX ID must be mapped to a Tioli Access Manager user. The user s UNIX username is obtained from the system s natie user registry using the numerical ID. This username is mapped one-to-one to a Tioli Access Manager user of the same name to retriee credentials from the Tioli Access Manager user registry. These credentials define the user s identity and group membership. If there is no Tioli Access Manager user corresponding to the user s natie username, then the user is treated as unauthenticated when making authorization decisions. Users with disabled accounts are also treated as unauthenticated. All systems sharing the same Tioli Access Manager enironment should use a consistent and distinct natie username for each real user in the enironment. For example, assume Sally Smith has a username of sally on Machine A and a username of ssmith on Machine B. She will be mapped to two different Tioli Access Manager users depending on which machine she logs into; this might affect the resources she can access. Conersely, assume Sally Smith has the UNIX username sally on machine A. User Sally Doe has the UNIX username of sally on machine C. Both Sally Smith and Sally Doe will get mapped to the same Tioli Access Manager user. Either of these situations might compromise your security policy. Chapter 1. Introduction 3

20 Authorization policy Credentials are initially retrieed or refreshed from the Tioli Access Manager user registry when a user logs into a UNIX system using a Tioli Access Manager for Operating Systems supported and defined login program while Tioli Access Manager for Operating Systems is running. All authorization decisions made for operations performed by processes subsequently run by this user are made using these credentials. This is true een for processes that change their effectie user ID, for example, programs that perform setuid() calls or programs run after successfully performing an su command. Setting up authorization policy inoles identifying the system resources that require protection and the degree of protection each resource needs. A security policy is successfully implemented when the appropriate access controls are applied on the resources requiring protection. The term access controls is used consistently throughout this guide to refer to the arious kinds of authorization policy that can be used to protect system resources. Access controls include: Access Control List (ACL) Identifies specific users, groups of users, and types of users who can be considered for access and specifies the operations permitted on the resource. Protected Object Policies (POP) Specifies conditions on access to the protected objects, such as auditing, warning mode, and time-of-day access. Extended Attributes Additional alues placed on an object, ACL, or POP that further restrict the access such as limiting what programs can be used to access a resource. In order to establish an effectie authorization policy, you should do the following: Understand your systems resources Identify the key resources that need to be protected Identify the types of users requiring access to these resources Understand the aailable Tioli Access Manager for Operating Systems options for securing the resources 4 IBM Tioli Access Manager for Operating Systems: Administration Guide

21 Chapter 2. Policy Policy administration IBM Tioli Access Manager for Operating Systems protects system resources by enforcing authorization policy defined in terms of Tioli Access Manager access controls. Access to the following types of system resources can be controlled: File system resources Remote network serices Local network serices Login serices Changes of user and group identity Sudo commands Password management serices These resources are identified by Tioli Access Manager object names. They are protected by associating Tioli Access Manager access controls with the object name. Tioli Access Manager access controls and object names are also used to specify resource-leel and user-leel audit policy. The following sections discuss how Tioli Access Manager object names and access controls are used to define authorization policy for the system resources that Tioli Access Manager for Operating Systems protects as well as resource-leel and user-leel audit policy. A Tioli Access Manager security administrator can use either the IBM Tioli Web Portal Manager Web-based graphical application or the pdadmin command line utility to manager users, groups, and authorization policy in a secure domain. Tioli Access Manager supports the capability to create and maintain multiple, secure domains. The initial domain is created when the master management (policy) serer is configured. This initial domain is referred to as the management domain. An administrator can create additional domains using the Tioli Access Manager administratie tools. Each additional domain has a unique name defined by the administrator when the domain is created. Domains are independent of each other. Users, groups, and resources defined within a domain are not associated with any other domain and authorization control oer resources within a domain does not extend to any other secure domain. A user or group continues to be identified by a name created within the domain, but, because multiple domains are supported, a gien LDAP user or group may hae a different identity within each domain. The Tioli Access Manager user or group identity is only unique within a specific domain. There are two primary adantages to maintaining multiple domains. The first is that each domain has its own policy database. Tioli Access Manager for Operating Systems replicates the database on each client machine eery time that a change is made to the policy database. This replication can result in a considerable amount of network traffic. Each client only needs the portion of the policy database that contains the policy for the branch to which it is configured. In an enironment where multiple policy branches are required, the size of the replicated database can be significantly reduced by organizing related branches into separate domains. Copyright IBM Corp. 2000,

22 Suppose you configured your enironment to hae the serer_branch in one domain (serer_domain) and the client_branch in another domain (client_domain). Each domain has its own policy database, independent of the other. Multiple endpoint machines can be configured to each branch. Changes made to the policy of one of the branches, for example, client_branch will cause policy updates to be sent only to those endpoint machines configured to client_domain. The second adantage is that users and groups can be completely separate from one domain to another. For example, the group osseal-admin could be defined in one domain to hae users root, osseal, liz, and anne as members and defined in another domain to hae users root, osseal, bill, and rusty defined as members. The same users or groups could also be shared across multiple domains by importing them into each domain. Note: If more than one domain is being used, a security administrator must log in to a specific domain in order to administer policy in that domain. System administrators should carefully consider the use of multiple domains when defining their security policy. Thought should be gien to disk space of the replicated policy database, network speed, common users, common groups, and policy. IBM Tioli Web Portal Manager is an optional component, packaged separately on platform-specific CD-ROMs, that are included with in the Tioli Access Manager for Operating Systems product package. For installation and usage information, see the IBM Tioli Access Manager Base Installation Guide and the IBM Tioli Access Manager Base Administration Guide. The pdadmin command line utility is installed as part of the IBM Tioli Access Manager Runtime Enironment. For more information about the pdadmin command, see the IBM Tioli Access Manager Command Reference. Examples of establishing policy in this guide are illustrated using the pdadmin command. These examples are always prefaced with the prompt: pdadmin>. Protected object name structure Eery resource has a protected object name that identifies the resource to Tioli Access Manager. After a protected object name has been defined, you can assign an access control to it. Protected object names are comprised of the following main parts: Namespace root Policy branch Resource type Object name Each of the parts of a protected object name are described below. Namespace root Eery resource manager under Tioli Access Manager has a namespace where all resource definitions are rooted. The namespace for Tioli Access Manager for Operating Systems is OSSEAL. All protected machines or nodes use OSSEAL. The OSSEAL namespace is /OSSEAL. 6 IBM Tioli Access Manager for Operating Systems: Administration Guide

23 Policy branch Your enironment probably has seeral machines that require the same or similar authorization policy because they are used for the same or similar purposes. Tioli Access Manager for Operating Systems lets you group the policy for similar machines under user-defined policy branches. Machines are configured to subscribe to a particular policy branch. All machines subscribing to the same policy branch are subject to the same authorization policy. The policy branch is specified by the element of the object name immediately following the /OSSEAL root. The administrator determines the name of the policy branches. When referred to generically in the remainder of this guide, the policy branch is referred to as /OSSEAL/policy-branch. Assume that you hae three classes of systems: serers, workstations, and test machines, each with different security requirements. You could define a policy branch for each class: /OSSEAL/Serers /OSSEAL/Workstations /OSSEAL/Test Resource types Beneath a policy branch lie all the resource types that can be protected. Resource types include system resources such as files and directories or other resources such as Sudo commands, Surrogate actions, Network resources, and Audit resources. The resource type specifies what kind of resource is being protected. For example, the protected object name for all protected file system resources starts as follows: /OSSEAL/policy-branch/File. Similarly, the protected object name for all Trusted Computing Base (TCB) secure files starts as follows: /OSSEAL/policy-branch/TCB/Secure-Files Object name Beneath the resource type are the actual resources themseles. Each resource type has specific objects that can be protected. For example, file resources protect files and directories. This is the lowest leel of a protected object name because it defines a single resource. For file system resources, the object name is the file or directory name. For network resources, the object name is the specified host and serice information. Each of the resource types specifies the information that identifies specific instances of that resource in this part of the object name. Many of the object names can represent system resources with names matching a wildcard pattern. The basic elements of the wildcard patterns are described in Wildcards. Each resource that makes use of wildcard patterns does so in different ways. Protected system resources on page 23 describes how each specific resource makes use of wildcards. Wildcards You can use wildcards to collectiely protect resources that are not contained in a hierarchy; for example, you could protect all files ending in.log or all host names beginning with www. Table 1 on page 8 describes the basic elements that make up a wildcard pattern. Chapter 2. Policy 7

24 Table 1. Wildcard Elements Wildcard Element Description * Matches a string of any length of characters, including slash (/) characters.? Matches any single character. + Matches one or more occurrences of the preious element. [set of characters] a character Matches a single character that is one of the set of characters. The set of characters is specified according to the POSIX wildcard expansion rules. For example, [a z] matches any ASCII character in the range from a to z. Matches the exact character specified. Use a backslash (\) to inhibit the special significance of the character that follows it. You can use two backslashes (\\) when you need to match a single backslash. Table 2 shows some wildcard patterns that match and some that do not match. Table 2. Wildcard Matching Examples Pattern Matching strings Non-matching strings a* a aa a quick brown fox a\* a* ab a? aa al /usr/local/*.log *.charity.org [[:alpha:]]+ * * (There is a space between the asterisks) /usr/local/x.log /usr/local/app/x.log ftp.charity.org abcd ABCD a b abcde ghijk lmnop ba q a oer the dog a aaa /usr/local/x.log.1 /abcd tty0 abcd the empty string Wildcard precedence For each kind of resource that makes use of wildcard patterns, Tioli Access Manager for Operating Systems must determine which wildcard pattern to apply. For example, assume that there are two patterns: /usr/local/*.log and /usr/local/user1/*.log The string /usr/local/user1/x.log matches both of these patterns. To resole this ambiguity, precedence rules are applied. The more specific a pattern, the higher its precedence. According to this principal /usr/local/user1/x.log is matched against the /usr/local/user1/*.log pattern before the /usr/local/*.log pattern. Because a match is found, any policy applicable to objects matching this pattern will apply. 8 IBM Tioli Access Manager for Operating Systems: Administration Guide

25 Table 3 shows the precedence of wildcard elements. Elements higher in the table hae precedence oer elements lower in the table. Table 3. Wildcard Element Precedence Rules Precedence Element Example 1 Exact character a, \*, \\ 2 Character range [Aa], [[:digit:]] 3 Arbitrary character? 4 Repeated exact characters a+ 5 Repeated character range [Aa]+, [[:digit:]]+ 6 Repeated arbitrary character?+ 7 Arbitrary string * Depending on the kind of resource, the precedence is determined by comparing the patterns, element by element, from beginning to end or in reerse. Patterns for matching file names are compared from beginning to end. Patterns for matching host names are compared from end to beginning. For two patterns otherwise considered equal, the longer pattern is considered more specific than the shorter pattern unless the longer string is longer because of an asterisk (*). Examples of wildcard precedence Table 4 shows file name and host name wildcard patterns arranged from highest precedence to lowest. Table 4. Wildcard Pattern Precedence Examples Precedence File name pattern Host name pattern 1 log/0[0 9]/error z]t.com 2 log/0?/error 3 log/0*/error 4 log/[0 9]+/error.1 www-help.[a z]+.com 5 log/*/error.1 www-help.*.com 6 log*/error.1 www-help.*.com 7 log*/error 8 log*/error* * 9 log* *.com 10 * * Access controls When the only difference between two patterns is the characters specified in a character set, precedence is determined by lexically comparing the two strings containing the patterns. This must be taken into account only if the character sets to be matched hae some of the same characters. If there are no common characters between the two sets, any gien string can match, at most, one of the patterns. Tioli Access Manager proides two basic kinds of access controls: Chapter 2. Policy 9

26 Access Control Lists Access Control Lists (ACLs) define access controls based on a user s identity and action performed or attempted. Protected Object Policies Protected Object Policies (POPs) define access controls based on other information (such as the time an access is occurring) and control aspects of an authorization decision such as whether or not the decision should be audited. Access controls are applied by defining ACLs and POPs and then attaching them to objects. The name of the object (the protected object name) represents the resource being protected. Tioli Access Manager proides two ways of defining the set of objects that may be protected: dynamically by a resource discoery mechanism, and statically by explicitly creating the objects in the policy database. Tioli Access Manager for Operating Systems uses the static mode. Eery object to be protected, that is, eery object that is to hae an ACL or a POP attached, must be explicitly created. For example, the pdadmin command: pdadmin> object create /OSSEAL/Serers/File/etc/passwd "Password file" \ 3 ispolicyattachable yes creates a Tioli Access Manager for Operating Systems File resource representing the /etc/passwd file with a description of Password file, type 3 (meaning file, and indicating that authorization policy might be attached to this object). Refer to the IBM Tioli Access Manager Command Reference for details about the object create command and other pdadmin commands. Tioli Access Manager proides resource managers with the capability to extend, in an application-specific way, the information contained in the policy database. Application-specific extended attributes are used to extend the meaning of the objects, ACLs, and POPs defined in the policy database. Tioli Access Manager for Operating Systems defines an extended ACL attribute, Access-Restrictions, to implement access control based on the program being used to perform an action. It defines two extended POP attributes, audit_permit_actions and audit_deny_actions, to enable more granular per-resource-leel auditing for authorization decisions based on the action being performed against the protected resource. It also defines extended object attributes to implement the Holidays, Login Actiity, Password Management, and Sudo resources. Login policy on page 41 and Sudo Policy on page 56 describe these extended attributes. The remainder of this section describes each type of access controls and how Tioli Access Manager for Operating Systems uses them. Access control lists An Access Control List (ACL) in the Tioli Access Manager enironment follows the discretionary access control model. Access to resources is controlled based on the identity of the user and the action that the user is performing. ACLs consist of a list of ACL entries. Each ACL entry has an accessor and a permission set. These components are denoted by the following notation in the examples below: accessor : permission-set A permission is represented by a single character that represents actions that may be performed on objects to which an ACL is attached. For example the x 10 IBM Tioli Access Manager for Operating Systems: Administration Guide

27 permission might represent permission to execute a program. The full set of permissions used by Tioli Access Manager for Operating Systems is described in the Table 5 on page 12. The accessor describes the users that the ACL entry is to apply to. The types of accessors are: user This accessor type defines an ACL entry that controls access to a resource for a particular user. The user s name is also specified in an accessor of this type. This user name must identify an existing Tioli Access Manager user. The following ACL entry grants the x permission to the root user. user root : x This kind of ACL entry has the highest precedence. If user root were a member of a group that was denied the x permission, this ACL entry would oerride that. Conersely, if user root were a member of a group that granted y permission, this ACL entry would hae precedence and deny root y permission on resources protected by this ACL. The username component of a user accessor in an ACL entry must be unique so that each user has only one user entry in an ACL. group This accessor type defines an ACL entry that controls access to a resource based on group membership. The group s name is also specified in an accessor of this type. This group name must identify an existing Tioli Access Manager group. The following ACL entry grants the y permission to the users group: group users : y Users are granted permissions based on group membership, which is indicated by all the permissions in group ACL entries for groups in which they are members. For example, if the user kein is a member of the groups users and sys-admin, but not net-admin, then the following ACL entries grant kein a and b permission but not c: group users : a group sys-admin : b group net-admin : c The group name component of a group accessor in an ACL entry must be unique so that each group has only one group entry in an ACL. any-other The any-other ACL entry grants permissions to any authenticated user that is not explicitly listed in a user entry within the ACL and is not a member of any groups listed in group entries within the ACL. An entry of this type allows definition of default permissions for authenticated users. The following entry grants q permission to any authenticated user not coered by a user or group entry in the ACL: any-other : q Only one any-other ACL entry may appear in an ACL. unauthenticated The unauthenticated ACL entry grants permissions to unauthenticated users. The UNIX identity and its relationship to the Tioli Access Manager user identity on page 3 explains the meaning of unauthenticated users in IBM Tioli Access Manager for Operating Systems. Unauthenticated users, by definition, hae no Tioli Access Manager user name nor can they be members of Tioli Access Manager groups. The following entry grants p permission to unauthenticated users: Chapter 2. Policy 11

28 unauthenticated : p Only one unauthenticated ACL entry may appear in an ACL. Unauthenticated users cannot be granted permissions that authenticated users do not hae. This means that any permissions granted by an unauthenticated ACL entry that are not granted by the any-other ACL entry are ignored. In the aboe example unauthenticated users would be granted p permission only if the ACL also has an any-other entry that grants the p permission. Permissions describe actions that can be performed on resources protected by Tioli Access Manager. The set of permissions specified in an ACL entry is the full set of permissions granted to users that match the accessor of that ACL entry. A user trying to perform an action not present in the permission set will be denied access to any resources the ACL is protecting. Permissions are defined by Tioli Access Manager actions. An action defines a single-letter mnemonic representing the permission, the name of the permission, the kind of the resource it applies to, and the action group of which it is a part. An action group is a collection of related actions. All Tioli Access Manager for Operating Systems actions are defined as members of the OSSEAL action group. Actions in the OSSEAL action group represent operations that may be performed on the resources that IBM Tioli Access Manager for Operating Systems protects. Table 5 defines all of the actions used by Tioli Access Manager for Operating Systems. Each permission is defined when it appears in this guide. Table 5. Permissions Defined in the OSSEAL Action Group Action Description Resource Type C Connect NetIncoming and NetOutgoing D Change directory File G Surrogate Surrogate K Kill program File L Login Login N Create File R Rename File U Update timestamp File d Delete File l List directory File o Change ownership File p Change permission File r Read File w Write File x Execute File and Sudo Tioli Access Manager defines actions that control access to policy management functions. Tioli Access Manager uses these actions to control who can modify the policy. These actions are all members of the primary action group. Policy management uses the primary actions in Table 6 on page IBM Tioli Access Manager for Operating Systems: Administration Guide

29 Table 6. Tioli Access Manager Primary Actions Used for Policy Management Action Description a Attach an ACL or POP b Browse object space and see object names c Control or modify an ACL d Delete an object m Modify an object s attributes View the attributes of an object The full meaning of these permissions is explained in the IBM Tioli Access Manager Base Administrator s Guide. Table 7 lists the two other primary Tioli Access Manager actions that affect the way authorization decisions are made. Table 7. Tioli Access Manager Primary Actions Used for Policy Decisions Action B T R Description Bypass protected object policies (POP) Traerse Bypass check for authorization rules Setting the B permission causes any POP policy associated with the object to be oerridden, for example, any time-of-day restriction applicable is not applied. Policy administrators need this permission in order to administer policy on objects that are subject to time-of-day access restrictions or haewarning audit leel enabled. See Protected object policies on page 21 for an explanation of POP attributes used for access control. The T, or Traerse, permission lets you control access to whole branches of resources efficiently. See Inheritance and traersal on page 19 for details. Setting the R permission causes the check for authorization rules to be bypassed. See the Tioli Access Manager base documentation for more information about authorization rules. When included in a permission set, all actions are prefixed by their action group name. For actions in the primary action group this is optional. An ACL entry for IBM Tioli Access Manager for Operating Systems typically looks like: user root: T[OSSEAL]rwx This indicates that the user root has the Tioli Access Manager for Operating Systems read, write, and execute permissions plus the Traerse permission. Other resource managers may define actions with mnemonic names similar to those used by Tioli Access Manager for Operating Systems. For example the Tioli Access Manager WebSEAL uses r to grant permission to read a Web page protected by WebSEAL. These permissions, despite haing the same mnemonic, are entirely separate and should not be confused. An ACL entry with the permission set Br[OSSEAL]wx does not grant IBM Tioli Access Manager for Operating Systems users read access to files that this entry s ACL may be protecting. Chapter 2. Policy 13

30 Access restrictions Tioli Access Manager for Operating Systems defines an extended attribute on an ACL that lets you control what programs users can use to perform particular actions. The name of the attribute is Access-Restrictions. Access to resources is controlled based on the identity of the user, the action that the user is performing, and the current program being used to perform the action. This restriction is in addition to the access control enforced by the base ACL that the attribute is associated with. Before an access restriction is applied the user must first hae been granted access by the base ACL entries. Entries for the Access-Restrictions attribute fall into two categories, permit entries and deny entries. Permit entries allow you to define policy that grants the accessor access to the protected resource for the specified actions if, and only if, the currently running program used to perform the action matches one of the programs listed in the program set. If a permit entry applies to a gien access and the currently running program does not match one of the programs listed in the entry s program set, access is denied. Deny entries allow you to define policy that denies the accessor access to the protected resource for the specified actions if the currently running program used to perform the action matches one of the programs listed in the program set. Only access using one of the programs listed in the entry s program set is restricted. A deny entry has no effect on accesses if the currently running program used to perform the action is not listed in the program set. Within entries of the same accessor type, deny entries hae a higher precedence then permit entries. The Access restrictions extended attribute can be defined for ACLs applied to any of the following resources: File, NetIncoming, NetOutgoing, Login, or Surrogate. It is meaningless to define an Access-Restrictions for Sudo resources because the accessing program is always the pdossudo command. See Sudo Policy on page 56 for a description of Sudo policy and the pdossudo command. The format for an extended attribute Access-Restrictions entry is: rule : accessor : permission-set : program-set The rule alue specifies what type of entry this is. Valid alues are permit or deny. Specifying a rule alue is optional. Attribute entries that do not contain a rule element will be enforced as a permit rule. The accessor describes the users that the extended attribute entry is to apply to. The types of accessors are the same as the accessor component of an ACL entry: user, group, any-other, and unauthenticated. The permission set is defined in the same way as in an ACL entry except that, because this extended attribute applies only to Tioli Access Manager for Operating Systems actions, you can omit the [OSSEAL] action group qualifier. It is important to group actions in the permission set. Only the attribute entries whose permission set contains all of the permissions associated with the actions being performed against the protected resource are ealuated to see if they apply to the current access decision. For example, if read and write access is requested, then only entries with both the r and w permissions (and possibly others) are 14 IBM Tioli Access Manager for Operating Systems: Administration Guide

31 considered. You can use the special permission set * to indicate that this entry applies to all possible actions in the OSSEAL action group. The program set is a space-separated list of programs. In a permit entry (the rule alue is either permit or not specified), the program set is the complete list of programs that the accessor is allowed to use to perform the actions specified in the permission set on the protected resource. The accessor is granted access to the protected resource for the specified actions if, and only if, the currently running program used to perform the action matches one of the programs listed in the program set. Access using a program not listed in the program set is denied. It is important that the program set contain a complete list of the programs that the accessor is allowed to use. Programs listed in a permit entry s program set are trusted to access the resource protected by the ACL. These programs are, therefore, included in the Trusted Computing Base. See Trusted Computing Base resources on page 30 for information about the Trusted Computing Base. The special program set * means that any program may be used to perform the actions. In a deny entry (the rule alue is deny), the program set is the list of programs that the accessor is not allowed to use to perform the actions specified in the permission set on the protected resource. The accessor is denied access to the protected resource for the specified actions if the current running program matches one of the programs listed in the program set. A deny entry has no effect on access if the currently running program used to perform the action is not listed in the program set. The special program set * means that no program can be used to perform the actions. Programs listed in a deny entry s program set are not included in the Trusted Computing Base. Within entries of the same accessor type, deny entries hae a higher precedence then permit entries. Types of restrictions that can be defined The Access-Restrictions extended attribute allows access to resources to be controlled based on the identity of the user, the action that the user is performing, and the current program being used to perform the action. The following types of restrictions can be expressed for accesses to the resource protected by the ACL with the AccessRestrictions attribute: The programs specified in the program set cannot be used by the accessor to perform the actions specified in the permission set: deny : accessor : permission-set : program-set Only the programs specified in the program set can be used by the accessor to perform the actions specified in the permission set: permit : accessor : permission-set : program-set accessor : permission-set : program-set The programs specified in the program set cannot be used by the accessor to access the protected resource regardless of the action: deny : accessor : * : program-set Only the programs specified in the program set can be used by the accessor to access the protected resource regardless of the action: permit : accessor : * : program-set accessor : * : program-set No program may be used by the accessor to perform the actions specified in the permission set: Chapter 2. Policy 15

32 deny : accessor : permission-set : * Any program may be used by the accessor to perform the actions specified in the permission set: permit : accessor : permission-set : * accessor : permission-set : * No program may be used by the accessor to access the protected resource regardless of the action: deny : accessor : * : * Any program may be used by the accessor to access the protected resource regardless of the action: permit : accessor : * : * accessor : * : * Access restriction ealuation When making an access decision, the base ACL entries are ealuated first. Access-Restrictions attribute entries associated with the base ACL controlling access to a protected resource are only ealuated if the base ACL granted the accessing user access to perform the specified action against the protected resource. When Access-Restrictions attribute entries are ealuated, the following rules are used to determine which, if any, entries apply to this access request. The term user s program refers to the currently running program being used to access the protected object. If no attribute entries apply that deny access, the access granted by the base ACL still applies and access is granted. If the user is authenticated, entries with accessor alues of user, group, and any-other apply. Only the attribute entries whose permission set contains all of the permissions associated with the actions being performed against the protected resource are ealuated to see if they apply to the current access decision. For example, if read and write access is requested, then only entries with both the r and w permissions (and possibly others) are considered. Entries with a permission set alue of * match all access requests regardless of the action being performed. Entries with the accessor type user hae the highest precedence during ealuation: if a deny rule entry is found with a user accessor type and the specified name matches the accessing user s name and the user s program or * is included in its program set, access is denied; if a permit rule entry is found with a user accessor type and the specified name matches the accessing user s name and the user s program or * is included in the entry s program set, access is granted; if access has not been granted by other user accessor type entries and a permit rule entry is found with a user accessor type and the specified name matches the accessing user s name and the user s program or * is not included in the entry s program set; access is denied; If no matching user accessor entries are found, entries with the group accessor type are ealuated: if a deny rule entry is found with a group accessor type and the specified name matches a group the accessing user is a member of and the user s program or * is included in its program set, access is denied; if a permit rule entry is found with a group accessor type and the specified name matches a group the accessing user is a member of and the user s program or * is included in its program set, access is granted; if access has not been granted by other group accessor type entries and a permit rule entry is found with a group accessor type and the specified name 16 IBM Tioli Access Manager for Operating Systems: Administration Guide

33 matches a group the accessor is a member of and the user s program or * is not included in the entry s program set; access is denied; If no matching user or group accessor entries are found, entries with the any-other accessor type are ealuated: if a deny rule entry is found with an any-other accessor type and the user s program or * is included in its program set, access is denied; if a permit rule entry is found with an any-other accessor type and the user s program or * is included in its program set, access is denied; if access has not been granted by other any-other accessor type entries and if a permit rule entry is found with an any-other accessor type and the user s program or * is not included in the entry s program set, access is denied. If the user is unauthenticated, only entries with accessor alue unauthenticated apply. As with authenticated users, only the attribute entries whose permission set contains all of the permissions associated with the actions being performed against the protected resource are ealuated to see if they apply to the current access decision: if a deny rule entry is found with an unauthenticated accessor type and the user's program or * is included in its program set, access is denied; if a permit rule entry is found with an unauthenticated accessor type and the user s program or * is included in the entry s program set, access is granted; if access has not been granted by other unauthenticated accessor type entries and if a permit rule entry is found with an unauthenticated accessor type and the user s program or * is not included in the entry s program set; access is denied. If no Access-Restrictions attribute entries apply that deny access, the access granted by the base ACL still applies and access is granted. For example, assume that the following Access-Restrictions attribute alues are defined. The base ACL grants the necessary access so that these entries will be ealuated and the ACL is attached to a File resource. permit : user root : r : * permit : group MgmtB : * : * permit : group ProjectB : rw : /opt/projectb/bin/applicationy deny : group RestrictAccess : * : * deny : any-other : * : * Please note that the entries shown are simply to facilitate explaining how ealuation works. It may be necessary to include other permissions in the permission set depending upon the resources being protected and the actions that need to be performed on them. If the user root attempts read access to the protected resource, the access will be allowed because the permit entry for accessor user root allows it. The user root would not be allowed to do other actions, such as write to the protected file, because the deny entry for accessor any-other denies it. The user root entry would not apply in this case because the permission set alue, r, does not contain the permission associated with the write action being performed, w. If a user, who is a member of both the RestrictAccess and ProjectB groups, attempts to access the protected resource for read and/or write using the program /opt/projectb/bin/applicationy, the access will be denied. This is because the deny entry for group RestrictAccess has higher precedence oer the permit entry for group ProjectB. Chapter 2. Policy 17

34 Users who are members of the group ProjectB and are not members the group RestrictAccess are allowed read and/or write access to the protected resource using the program /opt/projectb/bin/applicationy. They would not be allowed to do other actions such as change the ownership of a protected file because the deny entry for accessor any-other denies it. The group ProjectB entry would not apply in this case because the permission set alue, r, does not contain the permission associated with the change ownership action being performed, o. Users who are members of the group MgmtB and are not members the group RestrictAccess are allowed to use any program to perform any action against the protected resource. All other authenticated users are denied access to the protected resource for all actions regardless of the program being used. An entry like this is useful to ensure that access is not granted to a user unintentionally. For example, the Access-Restrictions attribute entries do not further restrict other actions for root user. Access inoling actions other then read would be controlled only by an entry such as this one or by the ACL entries in the base ACL to which these Access-Restrictions attribute entries hae been applied. To ensure that the root user cannot perform actions other then read, this type of entry should be defined or the base ACL entries should only allow read access for the user root. If the base ACL entries grant access other then read and this entry did not exist, the user root can use any program to perform the other actions. Example of access restrictions In the following examples, assume that the platform is AIX and Tioli Access Manager for Operating Systems is configured to use the policy-branch name Serers. Example 1: This example uses permit entries to allow all users read access to the /etc/passwd file, and to restrict any user who is not a member of the sys-admin group to only using the /usr/bin/passwd command to write to the file. 1. Create the base ACL that allows all authenticated users (any-other) and unauthenticated users rw access: pdadmin> acl create passwd pdadmin> acl modify passwd set any-other T[OSSEAL]rw pdadmin> acl modify passwd set unauthenticated T[OSSEAL]rw 2. Define Access-Restrictions extended attribute entries associated with this ACL to further control read and write access. a. Define a permit entry that allows users who are members of the group sys-admin read and write access using any program : pdadmin> acl modify passwd set attribute \ Access-Restrictions "group sys-admin:rw:*" b. Define permit entries that allow all other authenticated users (any-other) and unauthenticated users read access using any program: pdadmin> acl modify passwd set attribute \ Access-Restrictions "any-other : r : *" pdadmin> acl modify passwd set attribute \ Access-Restrictions "unauthenticated : r : *" c. Define permit entries that allow all other authenticated users (any-other) and unauthenticated users write access only when using the program /usr/bin/passwd: pdadmin> acl modify passwd set attribute \ Access-Restrictions "any-other : rw : /usr/bin/passwd" pdadmin> acl modify passwd set attribute \ Access-Restrictions "unauthenticated : rw : /usr/bin/passwd" 18 IBM Tioli Access Manager for Operating Systems: Administration Guide

35 3. Create a protected object name to control access to the /etc/passwd file and attach the passwd ACL: pdadmin> object create /OSSEAL/Serers/File/etc/passwd "passwd file" 3 \ ispolicyattachable yes pdadmin> acl attach /OSSEAL/Serers/File/etc/passwd passwd Example 2: This example uses both permit and deny entries to set up login restrictions that do the following: allows members of the group top-admin to login from any remote terminal using any program allows members of app-admin to login from any remote terminal using any program except by connecting to ftpd allows all other authenticated users to login from any remote terminal only by connecting to telnetd denies unauthenticated users login access from remote terminals 1. First create the base ACL that allows all authenticated users (any-other) login access (L) and denies unauthenticated users login access: pdadmin> acl create remote-login pdadmin> acl modify remote-login set any-other T[OSSEAL]L pdadmin> acl modify remote-login set unauthenticated T[OSSEAL] 2. Define Access-Restrictions extended attribute entries associated with this ACL to further control how authenticated users can log in based on their group membership and the program being used. a. Define a permit entry that allows users who are members of the group sys-admin to log in using any program: pdadmin> acl modify remote-login set attribute \ Access-Restrictions "permit : group sys-admin : L : *" b. Define a deny entry that restricts users who are members of app-admin from login using the /usr/sbin/ftpd daemon. Login through other programs is not restricted: pdadmin> acl modify remote-login set attribute \ Access-Restrictions "deny : group app-admin : L : /usr/sbin/ftpd" c. Define a permit entry that allows all other authenticated users (any-other) to log in from any remote terminal only when connecting to the /usr/sbin/telnetd daemon: pdadmin> acl modify remote-login set attribute \ Access-Restrictions "permit : any-other : L : /usr/sbin/telnetd" 3. Create a protected object name to control access from remote terminals and attach the remote-login ACL: pdadmin> object create /OSSEAL/Serers/Login/Terminal/Remote "remote login" 3 \ ispolicyattachable yes pdadmin> acl attach /OSSEAL/Serers/Login/Terminal/Remote remote-login Inheritance and traersal In the Tioli Access Manager enironment, resources can inherit ACLs from other resources. Examining the protections of file resources is an example of inheritance. For example, if you hae a directory named project01 on your system, the protected object name of this directory might be /OSSEAL/default/File/project01. By placing an ACL on the protected object name for the /project01 directory, which contains all of the files for a project, all the subdirectories and files in this directory inherit that ACL from project01. Chapter 2. Policy 19

36 Inheritance lets you easily apply policy to a number of resources by placing the ACL high up in the protected object name hierarchy. Inheritance applies to all resources. If a resource does not hae an ACL attached to it, Tioli Access Manager for Operating Systems traels up the protected object name until it finds an ACL. There are two are exceptions to this rule: Tioli Access Manager for Operating Systems, when protecting file system resources, always assumes that a permissie ACL, that is, an ACL that will grant all accesses, is attached to the root of the file system. This ensures that a system remains functional when Tioli Access Manager for Operating Systems is protecting it and also ensures that Tioli Access Manager for Operating Systems can make efficient authorization decisions when file system resources are accessed. Tioli Access Manager for Operating Systems can be configured to assume that permissie ACLs are attached at the /OSSEAL/branch/NetIncoming and /OSSEAL/branch/NetOutgoing points in the policy namespace, using the net_acl_limited configuration option (see Limiting ACL inheritance for network policy on page 120). This allows Tioli Access Manager for Operating Systems to make more efficient authorization decisions for network accesses, only generating authorization checks for network resources that are explicitly protected by an ACL. For example, assume that a user is trying to access a network resource with a protected object name of /OSSEAL/default/NetIncoming/tcp/telnet/ If that protected object name does not hae an ACL attached to it, Tioli Access Manager for Operating Systems looks to see if /OSSEAL/default/NetIncoming/tcp/telnet has an ACL attached to it. If this next leel up does not hae an ACL attached to it, Tioli Access Manager for Operating Systems looks to see if /OSSEAL/default/NetIncoming/tcp has an ACL attached to it. Tioli Access Manager for Operating Systems continues up the hierarchy in this manner until it finds an ACL it can use to make a policy decision, or until it reaches a point where there is an implicit permissie ACL (/OSSEAL/branch/NetIncoming) if limited network ACL inheritance is configured). When making a policy decision, Tioli Access Manager for Operating Systems uses the ACL lowest in the hierarchy. This lower-leel ACL completely oerrides any higher-leel ACL. For example, assume the following: Assume that you hae a file resource with a protected object name of /OSSEAL/serers/File/usr/games/solitaire. The solitaire game is a file, and usr and games are directories. You hae one ACL on the directory usr that gies eeryone full access and another ACL on solitaire that gies only the administrator full access. By inheritance, the games directory under usr is accessible to eeryone, but solitaire is accessible only by the administrator, no matter what ACL entries are present in the ACL at the usr directory. The only exception to the rule that an ACL lower in the hierarchy entirely oerrides a higher one is the behaior of the primary Tioli Access Manager Traerse permission (T). In order for a user to access a resource, that user must be granted Traerse permission in eery ACL higher in the hierarchy than the object being accessed. Traerse permission is not required to access the object itself. In the preious example, the administrator needs Traerse permission in the ACL 20 IBM Tioli Access Manager for Operating Systems: Administration Guide

37 Protected object policies attached at usr but not in the ACL attached at solitaire. If an ACL were placed at games, then the administrator would also require Traerse permission be granted by that ACL. Tioli Access Manager proides a form of access control called a protected object policy (POP). POPs define access controls that are not based on user identity or the action the user is performing; they also control other details about how an authorization decision is made. POPs, like ACLs, are defined by the administrator and are attached to objects in the Tioli Access Manager database that represent the resources being protected. POPs obey the same inheritance rules as ACLs. POPs and ACLs are inherited independently; you do not need to attach them at the same point in the object hierarchy. Any gien object might inherit access controls from an ACL attached at one point in the hierarchy and from a POP at another. In the preceding solitaire example, assume that a POP restricting time-of-day access at the games directory is defined. Access is controlled to solitaire by the ACL attached directly to it and, by inheritance, the POP attached aboe it at games. You can define arious attributes within a POP. Tioli Access Manager for Operating Systems uses the warning mode, audit leel, and time-of-day attributes. It does not use the quality of protection or IP endpoint authentication attributes. POP attributes used for access control POPs proide seeral attributes you can use to implement specific policies. Warning-mode attribute The access control warning-mode attribute enables you to implement trial policy. A protected object protected by a POP with warning set to yes has warning mode enabled. When an ACL denies access to an object with warning mode enabled, instead of the access being denied, it is granted and an audit record is generated. You can try policy by applying ACLs where you beliee they should go and then examining the audit trail to erify that accesses that should be denied are denied and accesses that should be granted are granted. Audit records are generated regardless of the audit leel setting in the POP when warning mode is enabled. See Enabling, disabling, and querying resource warning mode on page 202 for examples of the warning mode attribute. By default, warning mode is disabled. Audit-leel attribute The audit-leel access control specifies under what circumstances an access to an object generates an audit record. The audit leel is set to one or more of the following leels: permit deny admin error If enabled, an audit eent is generated when access to the resource is granted If enabled, an audit eent is generated when access to the resources is denied Does not apply to Tioli Access Manager for Operating Systems resources Does not apply to Tioli Access Manager for Operating Systems resources Chapter 2. Policy 21

38 all none All of the defined audit leels are enabled None of the defined audit leels are enabled. This is the default. To enable auditing based on the action being performed against the protected resource, extended attributes specifying the accessing permissions can be set on a POP in conjunction with the audit-leel attribute. The names of the extended attributes are audit_permit_actions and audit_deny_actions. Their formats are: audit_permit_actions permission-set audit_deny_actions permission-set The permission-set is defined in the same way as in an ACL entry. These extended attributes apply only to Tioli Access Manager for Operating Systems actions. The [OSSEAL] qualifier must be specified in front of the actions. The audit_permit_actions and audit_deny_actions extended POP attributes only take effect if the corresponding audit leel is enabled by the audit-leel attribute. If permit is enabled in the audit-leel attribute and the extended attribute audit_permit_actions is set to on in the POP, an audit record is generated when access to the resource is granted for the actions specified in the permission-set. Audit records are not generated when access to the resource is granted for actions not specified in the permission-set. If deny is enabled in the audit-leel attribute and the extended attribute audit_deny_actions is set to on in the POP, an audit record is generated when access to the resource is denied for the actions specified in the permission-set. Audit records are not generated when access to the resource is denied for actions not specified in the permission-set. See Setting and querying the resource audit leel on page 198 for examples of setting the resource audit leel. Further details about the audit leels are in the Tioli Access Manager documentation. Time-of-day attribute The time-of-day access control specifies days of the week and the times of the day that a resource can be accessed. The time-of-day access control specification is of the form: day-range : time-range where [:utc local] day-range Either anyday, weekday, or a comma-separated list of sun, mon, tue, wed, thu, fri, or sat. The anyday option indicates that the user is permitted access on any day of the week. The weekday option specifies that the user is permitted access on any day except for Saturday and Sunday. A list of days indicates that the user is permitted to access the resource only on the specified days. time-range Either anytime or a start time and end time. The anytime option indicates that the user is permitted to access the resource at any time on the days of the specified by the day-range. If time is specified in the form 22 IBM Tioli Access Manager for Operating Systems: Administration Guide

39 start_hhmm-end_hhmm, the start_hhmm specifies an hour followed by minutes past the hour, and the end_hhmm specifies the end time. Specify the hour in 24-hour format. utc local Specifies that the time-of-day restriction should be applied according to Uniersal Coordinated Time (UTC). Specifies that the time-of-day restriction should be applied according to the local time on the machine the user is logging in on. This is the default. Protected system resources By default, access is permitted on all days at all times. This section describes protected system resources as they are defined in the Tioli Access Manager for Operating Systems enironment. It specifies what resources can be protected, how the resources are defined in the policy namespace, and what actions can be defined for a resource. It also describes how resources are defined in the Trusted Computing Base (TCB) and how TCB resources are treated. File policy Tioli Access Manager for Operating Systems proides the ability to control access to file system resources. File systems resources consist of: Files Directories Soft links Hard links Deice files This section describes how access to each of these resources is affected when the authorization policy is applied to them. File system resources are protected in two ways: Access controls protect file system resources based on the identity of the user attempting the access and the action the user is trying to perform. They are applied to resources of type File. Membership in the TCB protects file system resources by monitoring the members contents and attributes for change. The membership of the TCB is defined by resources of type TCB. These two methods of protection are described in the following sections. File resources File system resources are represented in the Tioli Access Manager namespace by defining an object name with resource type File and specifying the name of the file system resource to be protected: /OSSEAL/policy-branch/File/filespec Table 8 on page 24 details the file system objects. Chapter 2. Policy 23

40 Table 8. File System Objects Object Name Description Type filespec An object name that represents a file system resource. The string specifies the full path name of the file resource being protected. The path name can contain wildcards. String conforming to the UNIX file-naming rules. Example File System Resources Some example file system resource specifications are: /OSSEAL/Default/File/etc/passwd /OSSEAL/Default/File/usr/local/*/*.log /OSSEAL/Default/File/usr/sbin/httpd The following restrictions apply when naming File resources: Access controls cannot be attached to the root directory, /. Tioli Access Manager for Operating Systems always assumes that permissie access controls are attached at /OSSEAL/policy-branch/File. An explicit ACL attached to the File object or higher is ignored for both access to the file system root directory (/) and for purposes of ACL inheritance. The first element of a file specification cannot contain wildcard elements (for example, /*.log or /*/tmp). Specific resources in the root directory can hae access controls. These restrictions ensure that authorization decisions can be made efficiently. Access control on file resources: The Tioli Access Manager for Operating Systems actions that apply to File resources are defined in Table 9. Tioli Access Manager ACLs can be placed at any point in a file system resource representation in the namespace. Normal Tioli Access Manager ACL inheritance rules apply to file system resources. This includes namespace traersal (T) permissions. An exception to the normal ACL inheritance model is the root of the file system namespace, for example, /OSSEAL/policy-branch/File. Tioli Access Manager for Operating Systems assumes that there is always an ACL at that point that permits access (and traersal) to eeryone. Thus, for the purposes of ACL inheritance, the effectie root of the namespace is at this position. In other words, an explicit ACL attached to the File object or higher is ignored for both access to the file system root directory (/) and for the purposes of inheritance. To define access control policy for the root directory, create a resource /OSSEAL/policy-branch/RootDir and attach access control policy (ACLs and POPs). See Access control on the root directory on page 26 for more information. Table 9 details the alid ACL permissions that can be associated with file system resources. Table 9. File Permissions Permission Name Read (r) Write (w) Permission granted Access a file system resource for reading. Access a file system resource for writing. 24 IBM Tioli Access Manager for Operating Systems: Administration Guide

41 Table 9. File Permissions (continued) Permission Name Create (N) Execute (x) Chown (o) Chmod (p) Chdir (D) Rename (R) Delete (d) Utime (U) Kill (K) List (l) Permission granted Create a particular file system resource. Execute a file system resource. Change the ownership of a file system resource. Change the natie UNIX file system permissions associated with a file system resource. This applies to both operations that modify UNIX mode bits and to operations that alter a resource s natie ACL for applicable platforms. Change directory into a file system directory resource (directories only). Moe (or rename) a file system resource. Remoe a file system resource. Modify the file access and modification times associated with a file system resource. Terminate a process that was executed from a file system resource. List the contents of a directory. Many of the permissions hae special behaiors or, where an equialent UNIX permission exists, slightly different behaior. These behaiors are as follows: The Kill (K) permission can be applied to the special File resource /OSSEAL/policy-branch/File/unix to control the ability to shut down or reboot the system. The Rename (R) permission interacts with the Create and Delete permissions. When renaming a file, in addition to Rename permission on the source file, the user must hae create permission on the target. If the target exists the user must additionally hae permission to delete it. For example, if a directory has the contents: log.1 log.bak then a user issuing the command: $ m log.1 log.2 in the directory must hae Rename permission on the file log.1 and Create permission on log.2. If the command $ m log.1 log.bak were issued, the user would need both Create and Delete permission on the file log.bak. The Change permission (p) permission also controls the ability to modify UNIX ACLs in addition to file permission. This applies only on systems that support this facility. The Execute (x) permission applies only to files. The UNIX x file permission also controls the ability to naigate a directory hierarchy. The Tioli Access Manager for Operating Systems Change directory permission (D) and primary Traerse (T) permission can be used together to control a user s ability to naigate file systems directories. Chapter 2. Policy 25

42 Access control on the root directory: Access control on the root directory (/) and its contents is accomplished using this special File resource, /OSSEAL/policybranch/RootDir. To define access control policy for the root directory (/), create the object /OSSEAL/policy-branch/RootDir and attach access control policy (ACLs and POPs). ACLs and POPs attached to the RootDir object apply to the root directory itself and files and directories residing in the root directory that are not goerned by policy defined under the File resource. Policy defined under the File resource takes precedence oer the policy defined for the RootDir object. When defining access control policy for the root directory, you should consider following: The policy goerning the RootDir object applies both to the root directory itself and its immediate content. Policy goerning RootDir applies to all files and directories residing in the root directory that are not goerned by policy defined under the File resource. For example, defining policy that is too restrictie may preent users from accessing directories commonly used by users and applications, such as /tmp and /home. No objects should be defined under the RootDir object. An error will be logged in /ar/pdos/log/msg pdosd.log if an object is defined under the /OSSEAL/policy-branch/RootDir object. Unlike objects defined as File resources, ACLs and POPs attached to the RootDir object are not inherited. An example of access control policy for the root directory (/) follows. The security administrator wants to protect the root directory and its contents that are not goerned by policy defined under the File resource. The administrator wants to define policy that gies all unauthenticated and authenticated users (any-other) read-only access to files and directories that reside in the root directory and allows them to change directory into directories that reside in the root directory, but does not allow them to create files or modify the contents of any files and directories residing in the root directory. The policy should also gie members of the admin group full access to the root directory and the files and directories residing in the root directory. In addition, all users should hae full access to the /tmp directory and its contents. For this example, the branch name is called system: pdadmin> object create /OSSEAL/system/RootDir "root dir" \ ispolicyattachable yes pdadmin> acl create rootdir_acl pdadmin> acl modify rootdir_acl set unauthenticated T[OSSEAL]Dlr pdadmin> acl modify rootdir_acl set any-other T[OSSEAL]Dlr pdadmin> acl modify rootdir_acl set group admin T[OSSEAL]DKNRUdloprwx pdadmin> acl attach /OSSEAL/system/RootDir rootdir_acl pdadmin> object create /OSSEAL/system/File/tmp "tmp dir" 0 \ ispolicyattachable yes pdadmin> acl create tmpdir_acl pdadmin> acl modify tmpdir_acl set unauthenticated T[OSSEAL]DNRUdloprwx pdadmin> acl modify tmpdir_acl set any-other T[OSSEAL]DNRUdloprwx pdadmin> acl attach /OSSEAL/system/File/tmp tmpdir_acl File system aliases: The file system proides the capability to define alias names for a resource. When a resource is accessed by an alias name, Tioli Access Manager for Operating Systems makes sure that the underlying resource is still protected. The file system aliases are: Symbolic links Hard links Deice files 26 IBM Tioli Access Manager for Operating Systems: Administration Guide

43 The following sections describe how Tioli Access Manager for Operating Systems enforces authorization policy when protected resources are accessed through the different kinds of alias names and when authorization policy is associated with an alias rather than the real resource. The major principles that define the way Tioli Access Manager for Operating Systems handles access controls in conjunction with alias names are: Access controls applied to an alias should protect the real resource in addition to the alias. Creation of a new alias should not allow access controls that already apply to the real resource to be bypassed. Keep these two principals in mind when reading the following sections. Symbolic links: First, consider how symbolic links affect the way policy is ealuated when access controls are not inherited. There are three possibilities: The target has access control directly applied to it. In this case, where the target of the symbolic link has an access control applied but the symbolic link does not, accesses to the resource by either name are controlled by the policy attached to the target. A symbolic link cannot be used to sidestep authorization policy. The symbolic link has access control applied to it. In this case, where the symbolic link has access control applied but the target does not, accesses to the resource by either name are also controlled by the same policy: that attached to the symbolic link. Both the target and the symbolic link hae access controls applied. In the case where access controls are applied to both the symbolic link and its target, accesses to the target directly are controlled only by the access control that is directly applied. Accesses ia the symbolic link are controlled by both sets of access controls and access is granted to the resource only if the accessor is permitted by both sets of access controls. Examples of symbolic link aliases: on symbolic links. The following are examples of the effect of policy Example 1: /usr/bin/i The file /usr/local/bin/i is a symbolic link to /usr/bin/i Assume that you hae this real file with an ACL attached to it: Then, when a user attempts to execute i by either name an authorization decision is made using the ACL attached to /usr/bin/i If, instead, the ACL was attached to /usr/local/bin/i, then it would still protect i no matter which of the names was used to access it. The protected object would be /usr/local/bin/i. If an ACL were attached to both /usr/bin/i and /usr/local/bin/i then accesses using the name /usr/bin/i are protected by the ACL attached to /usr/bin/i. Accesses ia the name /usr/local/bin/i are protected by both ACLs. Example 2: /home/joe/data Suppose Chapter 2. Policy 27

44 is a file with no access controls applied. /home/joe/data.link is a symbolic link to data with an ACL attached. /tmp/data/joe_data is a symbolic link to /home/joe/data also with an ACL attached. The following conditions affect the access to this resource. If the file is accessed directly using the name /home/joe/data, both ACLs must be passed before access is granted. If the file is accessed using either of the symbolic links, then both ACLs will also apply. If an ACL were to be attached directly to /home/joe/data, then when the file is accessed directly as /home/joe/data, only this ACL would apply. If the file is accessed by either of the symbolic links, then this ACL, plus the ACL on the two symbolic links, would apply. If the symbolic link is to a directory name rather than a file name, the same rules described aboe for files apply in this case as well with the resulting policy being inherited by the contents of the target directory. Example 3: The next case to consider is when either the target resource or the symbolic link is protected by inherited access controls rather than haing access controls applied directly. When a symbolic link has no access control directly applied to it, the target of the symbolic link is protected only by access controls that the symbolic link inherits when the target is accessed ia the symbolic link. When the target of a symbolic link has no access control directly applied to it, access controls inherited by the target are always applied whether the target is accessed directly or ia the symbolic link. Consider the following examples: Suppose that /home/joe/data is a file with ACL attached directly to it and that /tmp/data/joe_data is a symbolic link to /home/joe/data also with an ACL attached at /tmp/data. When the file is accessed directly, only the ACL attached directly is applied. When the file is accessed ia the name /tmp/data/joe_data both ACLs are applied. Example 4: Suppose that: /home/joe/data is a file this time with an ACL attached only at /home and that /tmp/data/joe_data is a symbolic link to /home/joe/data this time with an ACL attached directly to /tmp/data/joe_data. In this case, both ACLs are applied when the file is accessed by either name. Propagating access controls through symbolic links allows platform-independent policy to be established more easily, particularly in cases where file layouts differ only by which name for a resource is the real file and which is the symbolic link. Een so, care must be taken to understand the effects of applying Tioli Access 28 IBM Tioli Access Manager for Operating Systems: Administration Guide

45 Manager for Operating Systems authorization to a system in order to ensure that the enforcement of the policy you define is as you intend. When a symbolic link is created or deleted, the only access controls that apply are those that apply directly to the symbolic link or that the symbolic link inherits. Hard links: You can define hard links to create multiple directory entries for a file. Each of these directory entries must reside in the same file system. Accesses to files system resources that hae multiple hard links are controlled similarly to resources with symbolic links. Howeer, after hard links are created, there is no one hard link that can be considered the target or real resource. The following rules summarize the behaior: When accessing a hard link that has access controls directly applied, only those access controls are applied. When accessing a resource that does not hae any access controls applied, but has other hard links that do hae access controls directly applied, all of the other access controls must be passed to gain access to the resource. Only if no hard links of the resource hae access controls directly applied will access controls inherited by the accessed resource be applied. Examples of hard link aliases: hard links. The following are examples of the effect of policy on Example 1: Assume that /home/joe/data is a file with an ACL attached directly to it and that /home/data/joe_data is a hard link to /home/joe/data with no ACL attached to /home/data Accesses to /home/joe/data are subject only to the ACL attached directly to /home/joe/data. Accesses to /home/data/joe_data are also subject only to the ACL attached directly to /home/joe/data. Example 2: Assume that /home/joe/data is a file with no ACL attached to it and that /home/data/joe_data.1 and /home/data/joe_data.2 are both hard links to /home/joe/data each with their own ACL attached. Accesses to /home/joe/data are subject to both ACLs. Accesses to either /home/data/joe_data.1 or /home/data/joe_data.2 are each subject only to the ACL directly applied to them Because different hard links to a file can hae different UNIX file permissions, Tioli Access Manager for Operating Systems controls the creation of a new hard link in a special way. When creating a new hard link the user needs the following permissions: N R r w Create permission on the name of the new hard link. Rename permission on the target of the new hard link. Read permission on the target of the new hard link. Write permission on the target of the new hard link. When a hard link is deleted, only those access controls that apply to that hard link are enforced. Chapter 2. Policy 29

46 Deice files: Deice files represent an underlying resource of the system, for example, a printer or a disk deice. You can create a deice file that represents the same deice as an existing deice file. The creation of new alias files should not be used to bypass access controls that are applied to a deice. The same rules that apply to hard links apply to deice files. When accessing a deice file that has access controls directly applied, only those access controls are applied. When accessing a deice file that does not hae any access controls applied, and there are other deice files representing the same deice that do hae access controls directly applied, all of the other access controls must be passed to gain access to the resource. Only if no deice files representing the deice hae access controls directly applied will access controls inherited by the accessed resource be applied. Files accessed from NFS clients: Tioli Access Manager for Operating Systems policy can be placed on file system resources that are accessed by NFS clients. The access controls are defined based on the path that the NFS client would use to access the file. For instance, assume that there is a directory on an NFS serer called /usr/shared/hrtools/bin that is aailable to NFS clients through a mount point of /usr/tools/bin. Access controls can be applied to the file resource /usr/tools/bin/payroll to restrict access to the payroll executable file by the NFS clients. This policy would be applied to any file with an identical access path on any Tioli Access Manager for Operating Systems system, whether it is an NFS mount point or not. Howeer, these access controls would not apply to the direct access of the file on the NFS serer itself. Similarly, access controls on the NFS serer path of /usr/shared/hrtools/bin/payroll would hae no effect on the NFS clients accessing the file through the NFS mount. Because NFS is a stateless file access protocol, operations performed from one NFS client might not be immediately isible at other NFS clients accessing the same file system resources. As a result, Tioli Access Manager for Operating Systems policy might not be immediately enforced on an NFS client when the file is created, deleted, or renamed by another NFS client or on the NFS serer itself. For this reason, it is recommended that access controls on file resources accessed through NFS client-mounted paths be placed only on files that already exist and that are infrequently deleted or renamed. Directories and read-only files, such as executable files, are good candidates for such access controls. Trusted Computing Base resources Tioli Access Manager for Operating Systems proides the ability to define files on a system as being part of a trusted computing base. Files that are members of the trusted computing base are monitored for changes in ownership, UNIX file permissions, creation and modification timestamps, presence or absence on a system, content of the file, and the deice on which the file resides. These attributes are collectiely referred to as the file s signature. Tioli Access Manager for Operating Systems lets you grant special priileges to programs by defining them in the Trusted Computing Base (TCB). If the integrity of a program defined in the Trusted Computing Base is compromised, it should no longer be trusted with special priileges. Tioli Access Manager for Operating Systems detects changes that comprise the integrity of a registered program. When a change is detected, Tioli Access Manager for Operating Systems records that the program is untrusted and does not allow an untrusted program to be executed until an administrator explicitly retrusts it by using the pdosobjsig command. 30 IBM Tioli Access Manager for Operating Systems: Administration Guide

47 Special priileges are granted to programs by defining them in one of the following classes of TCB resources: Secure-Files Secure-Programs Login-Programs Impersonator-Programs Immune-Programs Immune-Surrogate-Programs A file might be classified as more than one type of Trusted Computing Base resource. The special priileges coneyed by these categories are detailed below. Files are created in the Trusted Computing Base by explicitly creating a Tioli Access Manager policy object of the appropriate name. Tioli Access Manager for Operating Systems enforces no authorization policy based on access controls applied on or beneath the /OSSEAL/policy-branch/TCB resource tree. Access controls are applied to files that are members of the Trusted Computing Base by attaching access controls to objects in the File resource tree. For example, to add the file /etc/hosts.equi as a Secure-File while permitting access only to root, use the following pdadmin commands: 1. Add hosts.equi to the TCB: pdadmin> object create /OSSEAL/Workstations/TCB/Secure-Files/etc/hosts.equi \ "Host equialents" 0 ispolicyattachable yes 2. Allow only root to access hosts.equi pdadmin> acl create hosts-equi pdadmin> acl modify hosts-equi set user root T[OSSEAL]NRUdoprw pdadmin> object create /OSSEAL/Workstations/File/etc/hosts.equi "hosts equi file" 3 ispolicyattachable yes pdadmin> acl attach /OSSEAL/Workstations/File/etc/hosts.equi hosts-equi Programs listed in any Access-Restrictions attribute entries with a rule type of permit or with no rule type specified are trusted to access the resource protected by the ACL. These programs are, therefore, included in the Trusted Computing Base, whether or not they are explicitly defined as Trusted Computing Base resources. All files in the Trusted Computing Base, regardless of the class they are specified in, are monitored for change. When a change is detected, the file becomes untrusted. The trust state of a file is recorded on a per-system basis. Access to untrusted files, in addition to any access controls applied to the file as a File resource, is further controlled as follows: When a file is initially added to the Trusted Computing Base by issuing the appropriate object create command in pdadmin, it is marked as trusted and its initial signature is recorded. An administratie audit eent is generated when the file s signature is detected to hae changed. An untrusted file cannot be executed, regardless of any access controls. Other accesses permitted by access controls, to an untrusted file (such as read), generate an administratie audit eent. If a file is recorded as a Trusted Computing Base file but does not exist on a system, that file is immediately untrusted on that system if it is created. If a file is recorded as a Trusted Computing Base file and is deleted, that file is marked untrusted and remains untrusted if re-created. Chapter 2. Policy 31

48 A file, after it is marked untrusted, can become trusted again only by an explicit action from the administrator. Use the pdosobjsig command to retrust a file. See pdosobjsig on page 250. The different types of Trusted Computing Base resources are defined as follows: Login-Programs UNIX systems hae no specific action that can be classified as a login. Tioli Access Manager for Operating Systems detects a user s login from the execution of arious Surrogate operations by specific programs. The specific programs are defined by their membership in the Login-Programs class of Trusted Computing Base files. Only certain programs hae been certified to work as Login-Programs in the Tioli Access Manager for Operating Systems enironment. These are the programs that are inoled in UNIX logins from locally attached terminals, graphical desktop enironments, and common network protocols (FTP, RLOGIN, TELNET, REXEC, RSH, SSH). Other programs might work and can be added to the Login-Programs class, but only the programs, as distributed by the operating system endor, listed in Table 10 hae been certified to perform logins in a manner that can be detected by IBM Tioli Access Manager for Operating Systems. None of the programs defined as Login-Programs by default should be remoed from the set unless the corresponding files are remoed from the systems being protected by Tioli Access Manager for Operating Systems. Doing so can compromise system security. Table 10. Login Programs Certified for IBM Tioli Access Manager for Operating Systems Platform AIX HP-UX Login Programs /usr/dt/bin/dtlogin /usr/sbin/ftpd /usr/sbin/getty /usr/sbin/login /usr/sbin/rexecd /usr/sbin/rlogind /usr/sbin/rshd /usr/sbin/sshd /usr/sbin/telnetd /usr/sbin/tsm /usr/bin/login /usr/bin/tsm /usr/dt/bin/dtlogin /usr/lbin/ftpd /usr/lbin/remshd /usr/lbin/rexecd /usr/lbin/rlogind /opt/ssh/sbin/sshd /usr/lbin/telnetd /usr/sbin/getty /usr/sbin/tsm 32 IBM Tioli Access Manager for Operating Systems: Administration Guide

49 Table 10. Login Programs Certified for IBM Tioli Access Manager for Operating Systems (continued) Platform Solaris Linux Login Programs /usr/bin/login /usr/dt/bin/dtlogin /usr/lib/saf/ttymon /usr/sbin/in.ftpd /usr/sbin/in.rexecd /usr/sbin/in.rlogind /usr/sbin/in.rshd /usr/local/sbin/sshd (freeware) /usr/lib/ssh/sshd (Solaris) /usr/sbin/in.telnetd /bin/login /sbin/getty /sbin/mingetty /usr/bin/gdm /usr/bin/gdmlogin /usr/bin/kdm /usr/sbin/in.ftpd /usr/sbin/in.rexecd /usr/sbin/in.rlogind /usr/sbin/in.rshd /usr/sbin/sshd /usr/sbin/in.telnetd /usr/sbin/in.tftpd /usr/sbin/in.wuftpd /usr/sbin/wu.ftpd /usr/x11r6/bin/xdm /usr/sbin/sftpd /opt/gnome2/bin/gdm /opt/kde2/bin/kdm /opt/kde3/bin/kdm If the actual location of sshd is not one of the paths listed in the preceding table and the administrator wants to support sshd as an Tioli Access Manager for Operating Systems login program, then the administrator must perform one of the following: Create a link from one of the expected paths to the actual path of sshd and re-trust sshd using pdosobjsig: # ln -sf /expected_path/sshd /actual_path/sshd # pdosobjsig -u /expected_path/sshd -s trusted Define a new login program resource with the correct actual path to sshd, using pdadmin to create the resource in the OSSEAL namespace: # pdadmin -a sec_master -p passwd pdadmin> object create \ /OSSEAL/policy_branch/TCB/Login-Programs/actual_path/sshd \ "sshd-daemon" 2 i yes On platforms that support PAM (Pluggable Authentication Modules), which include Linux, Solaris, and HP-UX, the sshd daemon must also hae been compiled with support for PAM. This support can be checked by running the ldd command against the sshd executable and checking that it links with the shared library libpam. Support of sshd as a login program requires that Tioli Access Manager for Operating Systems login policy be configured. You can determine the Chapter 2. Policy 33

50 current configuration by checking pdosd.conf. If login policy enforcement is off, you can enable it by using pdoscfg: # cat /opt/pdos/etc/pdosd.conf grep login login-policy = off # pdoscfg -login_policy on Secure-Files Secure files are granted no special priileges. They are simply monitored for changes in their signature. IBM Tioli Access Manager for Operating Systems defines some Tioli Access Manager for Operating Systems files as Secure-Files when initially configured. No system files are predefined as Secure-Files. Secure-Programs Many UNIX programs require UNIX priileges that are different from the UNIX permissions of the users who can run them. Such programs are marked with the set user ID or set group ID permissions and might include commands such as su, mail, or telnet. Without any special action, the change of UNIX identity that occurs when such programs are executed would require the inoking user to hae the Tioli Access Manager for Operating Systems authority to Surrogate to the target user and group indicated by the ownership attributes of the program. For example, on systems where the mail program is set UID root, eery user should probably be able to run the mail program. Howeer, eery user should likely not be authorized to Surrogate to root. See Surrogate policy on page 53 for more information. Programs defined in the Secure-Programs class of Trusted Computing Base files are treated as exempt from Surrogate policy when the initial UNIX identity changes are performed as the program is executed. If, while the program is executing, it changes UNIX user or group identity again, this subsequent change is subject to Surrogate policy. Subsequent surrogate operations performed by the program after the initial UNIX identity changes are subject to Surrogate authorization policy. Tioli Access Manager for Operating Systems policy goerning the execute action itself would still be enforced. The only system program defined as a Secure-Program by Tioli Access Manager for Operating Systems when initially configured is the su program. If you want to establish restrictie Surrogate policy, you need to determine which set UID and set GID files you need to add to the Secure-Programs class of TCB files to allow them to continue to be used by ordinary users who would otherwise be restricted from performing the required Surrogate operation. The pdosuidprog command described in pdosuidprog on page 271 locates set UID and set GID programs on your system. The following IBM Tioli Access Manager for Operating Systems programs are defined as Secure-Programs: /opt/pdos/bin/pdosdestroy /opt/pdos/bin/pdoslpadm /opt/pdos/bin/pdosrefresh /opt/pdos/bin/pdossudo /opt/pdos/bin/pdosunauth /opt/pdos/bin/pdoswhoami /opt/pdos/bin/pdoswhois /opt/pdos/sbin/kosserrs /opt/pdos/bin/pdosshowuser /opt/pdos/bin/rc.lpm 34 IBM Tioli Access Manager for Operating Systems: Administration Guide

51 Immune-Surrogate-Programs The Immune-Surrogate-Programs class proides the ability to define a program as being immune to all surrogate policy. Programs registered under this class are immune to all surrogate policy regardless of whether or not the surrogate operation was performed at execution time (because the program was a set UID or set GID program) or during runtime (due to the use of setuid()/setgid() system calls). Tioli Access Manager for Operating Systems policy goerning the execute action itself would still be enforced. The Immune-Surrogate-Programs class is an extension of the Secure-Programs class to coer situations where registering a program in the Secure-Programs class is not sufficient. For example, some set UID root programs perform subsequent surrogate operations following the initial UNIX identity change done at execution. In an enironment where restrictie Surrogate-to-root policy is established, it might be desirable to allow an ordinary user to use such a program without the subsequent surrogate operations being subject to the restrictie Surrogate-to-root policy. Registering such a program in the Secure-Programs class is not sufficient because only the initial UNIX identity is exempt from surrogate policy enforcement. No programs are predefined as Immune-Surrogate- Programs. Impersonator-Programs UNIX systems generally proide a mechanism (for example, cron) for users to schedule jobs to be executed as batch operations while they are not logged in to the system. Such programs typically run as the root user and, when executing a task, change identity to the user who scheduled the task. That change of identity is iewed as a Surrogate operation and without special action would run with root s Tioli Access Manager for Operating Systems credentials and not the user s credentials because Surrogate operations do not change the Tioli Access Manager for Operating Systems accessor ID of a process. A program s membership in the Impersonator-Programs class of the Trusted Computing Base instructs Tioli Access Manager for Operating Systems to change the accessor ID of a process running the program when the process changes its effectie UNIX user ID. If you hae restrictie Surrogate policy you might need, for example with cron, to permit root to Surrogate to otherwise restricted users. Do this by specifying an Access-Restrictions attribute that allows the Surrogate operation only when using the cron The only Impersonator-Program defined by IBM Tioli Access Manager for Operating Systems when initially configured is the cron program. Immune-Programs A program might be integrated so tightly to a system that if a process running that program was subject to authorization policy as enforced by Tioli Access Manager for Operating Systems, the system would cease to function. You can mark such programs as immune from all Tioli Access Manager for Operating Systems policy by making them a member of the Immune-Programs class of the Trusted Computing Base. Execution of immune programs is subject to authorization as for any other program but when it is running the program is immune to all Tioli Access Manager for Operating Systems authorization policy. This immunity includes auditing; no operations that a running immune program performs are audited. Chapter 2. Policy 35

52 A process s immunity is not inherited by any child programs spawned by that process. Tioli Access Manager for Operating Systems defines the system programs listed in Table 11 as immune in the default policy. They represent system processes inoled in file system operations, user identity mapping, and error logging. Table 11. System Programs Defined as Immune-Programs in Default Policy Platform AIX HP-UX Solaris Linux Immune Programs /usr/bin/aixpowermgtdaemon /usr/ccs/bin/shlap /usr/ccs/bin/shlap64 /usr/lib/errdemon /usr/lpp/diagnostics/diagd /usr/sbin/automountd /usr/sbin/biod /usr/sbin/nfsd /usr/sbin/rpc.lockd /usr/sbin/rpc.statd /usr/sbin/syncd /usr/sbin/syslogd /usr/lib/netsc/fs/autofs/automountd /usr/lib/netsc/fs/automount/automount /usr/sbin/biod /usr/sbin/nfsd /usr/sbin/pwgrd /usr/sbin/rpc.lockd /usr/sbin/rpc.statd /usr/sbin/syncer /usr/lib/autofs/automountd /usr/lib/nfs/lockd /usr/lib/nfs/nfsd /usr/lib/nfs/statd /usr/sbin/rpcbind /usr/sbin/syslogd /sbin/klogd /sbin/portmap /sbin/rpc.lockd /sbin/rpc.statd /sbin/syslogd /usr/sbin/apmd /usr/sbin/automount /usr/sbin/rpc.quotad /usr/sbin/rpc.mountd /usr/sbin/rpc.nfsd In addition to the system programs listed in Table 11, the following Tioli Access Manager for Operating Systems programs are defined as Immune-Programs on all platforms: /opt/pdos/bin/pdosauditd /opt/pdos/bin/pdosaudiew /opt/pdos/bin/pdosbkup /opt/pdos/bin/pdoscfg /opt/pdos/bin/pdosctl /opt/pdos/bin/pdosd /opt/pdos/bin/pdosexempt /opt/pdos/bin/pdoslpmd /opt/pdos/bin/pdosobjsig /opt/pdos/bin/pdosreoke 36 IBM Tioli Access Manager for Operating Systems: Administration Guide

53 /opt/pdos/bin/pdosteccfg /opt/pdos/bin/pdostecd /opt/pdos/bin/pdostecucfg /opt/pdos/bin/pdoswdd /opt/pdos/bin/pdoslrd /opt/pdos/bin/pdoslrdadm The following Tioli Access Manager for Operating Systems kernel files are also defined as Immune-Programs: /opt/pdos/kernel/kossd /opt/pdos/sbin/ossdump.sh /opt/pdos/sbin/kazntrace /opt/pdos/sbin/kossdump.sh /opt/pdos/sbin/kosserrs /opt/pdos/sbin/kossinfo /opt/pdos/kernel/kossctl It is important to understand the differences among the Immune-Programs, Secure-Programs, and Immune-Surrogate-Programs classes: Programs defined in the Immune-Programs class are immune from all Tioli Access Manager for Operating Systems policy enforcement after they are up and running. Tioli Access Manager for Operating Systems policy goerning the execute action itself would still be performed. Programs defined in the Secure-Programs class are treated as exempt from Surrogate policy enforcement for the initial UNIX identity changes performed as the program is executed. Tioli Access Manager for Operating Systems policy goerning the execute action itself would still be enforced. If such a program performs subsequent surrogate operations after the program has been executed, then these operations are subject to Surrogate authorization policy. Programs defined in the Immune-Surrogate-Programs class are treated as exempt from Surrogate policy enforcement for the initial UNIX identity change that happens as the program is executed and any subsequent surrogate operations after the program is running. Tioli Access Manager for Operating Systems policy goerning the execute action itself would still be performed. Proiding all three classes allows for granular control of programs that might require special priileges to function properly in a highly secure enironment. Deciding which classification is appropriate for any gien program requires careful study of what protected resources the program needs access to while running. For example, determining if a program needs to be registered in either the Secure-Programs or Immune-Surrogate-Programs class requires careful study of the surrogate operations that the program performs and a determination of whether the target users are protected by restrictie surrogate policy. It is possible to classify a program under more than one class. This should be done carefully, with a full understanding of the program s behaior. For cases where the special priileges oerlap, registering a program in more than one class is redundant and unnecessary. For example, registering a program in the new Immune-Surrogate-Programs class proides a superset of the priileges granted to programs registered in the Secure-Programs class. While it is possible to register the same program in both of these classes, it is unnecessary. Network policy Tioli Access Manager for Operating Systems proides the ability to control access to remote network serices from a local machine and also to control access to local network serices from remote locations. These two types of network access are Chapter 2. Policy 37

54 controlled separately by defined, protected resources of type NetOutgoing and NetIncoming, respectiely. These resources are represented in the Tioli Access Manager namespace as: /OSSEAL/policy-branch/NetIncoming/protocol[/serice[/host]] /OSSEAL/policy-branch/NetOutgoing[/hostspec[/protocol[/serice]]] The inheritance of access controls beyond the /OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing points in the namespace limits the performance of network authorization decisions. If it is not necessary to place a restrictie ACL at or aboe these points in the namespace, the performance of network authorization decisions can be improed by limiting the inheritance of network authorization to below these points in the namespace. This is done using the -net_acl_limited option to pdoscfg (see the IBM Tioli Access Manager for Operating Systems Installation Guide or pdoscfg on page 225, pdoscfg, for more information on the usage). When this limitation is enabled, it is assumed that the access control at these points in the namespace is permissie (as is done with the root of the file system namespace, /OSSEAL/policy-branch/File), and the authorization decisions can be made more efficiently when network resources are accessed. Table 12 details the elements of the network policy object names. Table 12. Network Resource Naming Object Name Description Type protocol serice host ip-address A representation of a network protocol name. The only supported protocol is TCP oer IP ersion 4. This protocol is represented by the string tcp. A description of the set of serices represented by this resource. For NetIncoming resources, this serice represents the serice on the local machine to which an incoming connection has been addressed. For NetOutgoing resources, this serice represents the serice on the remote machine to which a connection attempt is being made. A description of the set of hosts represented by this resource. For NetIncoming resources, this represents remote hosts from which an incoming connection is attempted. For NetOutgoing resources, this represents the remote host to which an outgoing connection is being attempted. A dotted notation of an IP address, for example, A case-sensitie string representing the protocol. A comma-separated list of ports and port ranges. Ports can be specified explicitly by number or by name. Port names are mapped to port numbers according to the mapping defined in the /etc/serices file on the machine where the network policy is being enforced. The special port range * is equialent to the range Only one of * or can be present in your policy. The host specification may be in one of two forms: ip-address[:nbits] hostname A string representing an IP ersion 4 address. 38 IBM Tioli Access Manager for Operating Systems: Administration Guide

55 Table 12. Network Resource Naming (continued) Object Name Description Type nbits hostname The number of bits considered significant in an ip-address. Bits are counted from left to right. 0 indicating that no bits are significant and 32 indicating that all bits are significant. When a host is specified in the ip-address[:nbits] form and no nbits component is specified, 32 is assumed. A wildcard string matching the names of the hosts represented by this resource. A number in the range 0 to 32. A case-insensitie string consisting of wildcard elements and legal host name characters. Example of network resources Some network resource specification examples are proided below: /OSSEAL/Default/NetIncoming/tcp/80 /OSSEAL/Default/NetIncoming/tcp/telnet/*.de.company.com /OSSEAL/Default/NetOutgoing/ :24/tcp/23 /OSSEAL/Default/NetOutgoing/ For both NetIncoming and NetOutgoing, the only permission used in ACLs to control access is the Connect (C) permission. Table 13. Valid Permission for Incoming or Outgoing Connection to a Network Resource Permission Name Connect (C) Description Permission to establish an incoming or outgoing connection to a network resource. Network serice and host pattern precedence When a network access is attempted, Tioli Access Manager for Operating Systems must determine which protected object name represents that access. The access probably matches more than one of the configured object names. For example, the host name matches both and Similarly, the telnet serice (port 23) matches the port range 23,513 and the range *. By matching against the most specific pattern first, Tioli Access Manager for Operating Systems lets you first establish a broad policy and then define exceptions. The structure of object names is also important when determining their precedence. For each of NetIncoming and NetOutgoing, the higher object name components hae higher precedence than the lower components. For example, with the two objects: NetOutgoing/ NetOutgoing/ an outgoing http connection to is protected by policy attached to the first object because the host component of the object name has the highest precedence. In the NetIncoming case with the two objects: Chapter 2. Policy 39

56 NetIncoming/tcp/*/serer.ibm.net NetIncoming/tcp/ftp/* an incoming ftp request from serer.ibm.net to the protected system is authorized based on policy applied to the second object name, not the first. The precedence rules for determining which serice pattern is used are the same for both NetIncoming and NetOutgoing. The precedence rules for determining which host pattern is used is also the same. Host pattern precedence describes the precise rules. Serice pattern precedence Serice pattern precedence is determined by the following rules: Patterns representing a smaller number of distinct ports hae higher precedence than those representing more. If two serice patterns represent the same number of ports, then the one with the lowest port number has higher precedence. If two serice patterns represent exactly the same ports, but are not represented identically in the object space, then they are considered ambiguous. One of them will be arbitrarily rejected from policy, and the PDOSD daemon generates warnings in its error log and administratie audit eents warning that ambiguous policy was rejected. Consider the following examples: The pattern telnet has higher precedence than because telnet represents just one port while represents 6. The pattern has higher precedence than because although both patterns represent 6 ports, 20 is less than 21. The pattern 20 25,50 60 has higher precedence than 20 25,60 70 because although both patterns represent 17 ports, 50 is less than 60. The patterns 1 10,23 30 and 1,2,3,4 9,10,telnet,24 30 are ambiguous because they represent exactly the same set of ports. Host pattern precedence Host pattern precedence is determined by the following rules: Host patterns of the form ip-address[:nbits] patterns always hae higher precedence than patterns specified as host names. If two ip-address[:nbits] patterns with the same ip-address component are present with one specifying an nbits component of 32 and the other not specifying an nbits component at all, the policy is considered ambiguous. One of the objects will be arbitrarily rejected and the pdosd daemon generates warnings in its error log and administratie audit eents indicating that ambiguous policy was rejected. ip-address[:nbits] patterns with more significant bits (nbits is a larger number) hae higher precedence than those with fewer significant bits. Host patterns specified as possibly wildcard host names hae precedence according to the wildcard element precedence and are compared from end to beginning. See Wildcards on page 7 for information about wildcard pattern precedence. Consider the following examples: The pattern :32 has higher precedence than the pattern : IBM Tioli Access Manager for Operating Systems: Administration Guide

57 If has IP address then the pattern :32 has higher precedence than the pattern This policy is not considered ambiguous because the ip-address[:nbits] pattern always has higher precedence. If has IP address then the pattern :16 has higher precedence than the pattern The ip-address[:nbits] pattern always has higher precedence than host name patterns. The pattern has higher precedence than because host name patterns are compared from end to beginning. Network resource access control Authorization decisions made when an outgoing network connection is attempted answer the question: Is the accessing user allowed to connect to the requested serice on the specified remote host? Authorization decisions made when an incoming network connection arries at a host answer a slightly different question. Tioli Access Manager for Operating Systems has no knowledge of the remote user making the incoming network connection request. The accessor is considered to be the accessor ID of the process accepting the incoming connection. The question being answered when making the authorization decision for NetIncoming resources is: Is the user allowed to accept incoming connections for the requested serice from a particular remote machine? The user that must be gien access by any ACLs placed on NetIncoming resources, therefore, is typically the root user because the processes that run on a machine that accepts incoming connections to system serices typically run as the root user. Application serices that are accessible oer the network often run as a user other than the root user. For these serices, it is that user who must be granted access by any ACLs protecting the NetIncoming resource. Login policy Tioli Access Manager for Operating Systems lets you control when and from where a user can log in to a system. The basic mechanisms for controlling user access are: Defining time-of-day login restrictions for users independent of where they log in from Defining access controls on local and remote terminals Tioli Access Manager for Operating Systems also proides the ability to enforce login-actiity-related policy such as password expiry, automatically disabling accounts after a number of failed logins, and automatically disabling inactie accounts. Time-of-day login restrictions Time-of-day login restrictions are defined by specific policy attributes in the Tioli Policy Director user registry. They can be specified globally, on a per-user basis, or specifically for unauthenticated users. Time-of-day restrictions define hours of the day and days of the week during which users are permitted to log in. For users defined in the Tioli Access Manager user registry, any user-specific policy oerrides any global policy. For users not defined in the Tioli Access Manager user registry, and, therefore, treated as unauthenticated by Tioli Access Manager for Operating Systems, the per-user policy associated with the special osseal-unauth user oerrides any global policy. Chapter 2. Policy 41

58 A time-of-day restriction is defined by a string of the following format: day-range:time-range[:utc local] where: day-range Either anyday, weekday, or a comma-separated list of sun, mon, tue, wed, thu, fri, or sat. The anyday option indicates that the user is permitted to log in on any day of the week. The weekday option specifies that the user is permitted to log in on any day except for Saturday and Sunday. A list of days indicates that the user is permitted to log in only on the specified days. time-range Either anytime or a start time and end time. The anytime option indicates that the user is permitted to log in at any time on the specified days of the week. If time is specified in the form start_hhmm-end_hhmm, the start_hhmm specifies the hour followed by minutes past the hour for the start time, and the end_hhmm specifies the end time. utc local Specifies that the time-of-day restriction should be applied according to Uniersal Coordinated Time (UTC). Specifies that the time-of-day restriction should be applied according to the local time on the system being logged on to. This is the default. Use the Tioli Access Manager administration command pdadmin to set time-of-day restrictions. The following are examples of time-of-day login policy usage: To permit all users to log in only on weekdays from 9:00 A.M. to 5:00 P.M. local time, while permitting the root user to log in at any time, enter: pdadmin> policy set tod-access weekday: :local pdadmin> policy set tod-access anyday:anytime -user root To additionally constrain unauthenticated users to be allowed to log in only on Mondays, enter: pdadmin> policy set tod-access mon: :local -user \ osseal-unauth To restrict logins regardless of local time zone where the logins take place, enter: pdadmin> policy set tod-access weekday: :utc pdadmin> policy set tod-access anyday:anytime -user root pdadmin> policy set tod-access mon: :utc -user \ osseal-unauth Setting holiday login restrictions You can specify additional time-of-day restrictions by defining Holidays. Holidays are protected resources that define exceptions to the regular time-of-day restrictions defined in the user registry. Holiday policy is applied when a user logs in. You define a holiday by creating an object with the appropriate attributes set on it. Gie the object a name that describes the holiday. The ability of a user to log in on the holiday is controlled by the ACL attached to the same resource. The Login (L) permission must be granted to those users allowed to log in. The format of the alue of the Holiday-Dates extended attribute is a start time followed by an optional space and an end time. The specified time format follows: YYYY-MM-DD[-hh[:mm[:ss]]][Z] 42 IBM Tioli Access Manager for Operating Systems: Administration Guide

59 Where: YYYY Year specified as four digits. MM Month specified as a number from 1 to 12. DD Day of the month specified as a number from 1 to 31. hh Hour of the day specified from 0 to 23. mm Minute of the hour specified from 0 to 59. ss Second of the minute specified from 0 to 59. Z Specifies use UTC instead of local time The following rules apply when interpreting start and end times that are only partially specified: If no end time is specified, the holiday period ends at midnight of the same day on which it started. Any time component not specified with a start time defaults to zero. If an end time is specified with year, month, and day, but no hour, minute, or second, the holiday period ends at midnight of the day specified. If an end time is specified with the hour or the hour and minute, any unspecified components default to zero. If either start time or end time are specified in UTC, then their time stamps are interpreted as UTC. Example of holiday login: Assume that there is a three-day holiday around the CEO s birthday, January 18. Only system administrators are allowed to work on January 17, 18, and 19. You could use the following commands to code the Holiday Restriction: pdadmin> object create /OSSEAL/Serers/Login/Holidays/CEO-Birthday-Time "Happy" \ 0 ispolicyattachble yes pdadmin> object modify /OSSEAL/Serers/Login/Holidays/CEO-Birthday-Time \ set attribute Holiday-Dates " :00: :00:00" Then create the ACL for the holiday. pdadmin> acl create ceo-birthday-time-acl pdadmin> acl modify ceo-birthday-time-acl set group sys-admins \ T[OSSEAL]L pdadmin> acl attach /OSSEAL/Serers/Login/Holidays/CEO-Birthday-Time \ ceo-birthday-time-acl This policy permits only members of the Tioli Access Manager group sys-admins to log in between 9:00 A.M. January 17, 2001 and 5:00 P.M. on January 19, Specifying recurring holidays You can specify recurring holidays by specifying multiple alues for the Holiday-Dates extended attribute. To define the same CEO birthday policy for the year 2002, you can add the following command: pdadmin> object modify /OSSEAL/Serers/Login/Holidays/CEO-Birthday-Time \ set attribute \ Holiday-Dates " :00: :00:00" You can also specify holidays that hae oerlapping ranges. In such cases, the policy that is applied at any time is determined by the following rules: The holiday range with the shortest period, if specified, is obsered. Chapter 2. Policy 43

60 For holiday ranges with the same period, the holiday range with the earliest start time is obsered. Oerlapping ranges specified as multiple alues are not combined to form one long range To continue the example, if een system administrators were not allowed to log in on the actual birthday of the CEO, January 18, the following holiday policy could be defined: pdadmin> object create/osseal/serers/login/holidays/ceo-birthday \ "VeryHappy" 0 ispolicyattachable yes pdadmin> object modify /OSSEAL/Serers/Login/Holidays/CEO-Birthday \ set attribute \ Holiday-Dates " :00: :00:00" With the policy for both the CEO-Birthday holiday and the CEO-Birthday-Time holiday in effect, when a system administrator attempts to log in after 9:00 A.M. on January 17, the time matches the CEO-Birthday-Time holiday range and the login is successful. If the system administrator attempts to log in after 9:00 A.M. on January 18, the attempt is denied. The shorter time of the CEO-Birthday holiday gies it precedence and the login is not successful. If you attempt to define multiple holidays with the identical Holiday-Dates attributes, the pdosd log file warnings indicate ambiguous policy specifications. The attempts are not allowed. Structure of holiday object names: The structure of the object names beneath the Holidays resource type specifier is free form. You can structure the definition of holiday definitions to use the ACL inheritance. If you define holidays to use ACL inheritance, be aware that the precedence rules carry across all defined holidays within a policy branch without regard to any user-defined hierarchy. For example, you can define holidays named as: /OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2001 /OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2002 /OSSEAL/policy-branch/Login/Holidays/CEO-Birthday/2003 with different date ranges specified for each year by attaching separate Holiday-Dates attributes for each of the leaf nodes. You could then attach a single ACL to CEO-Birthday. Login location restrictions You can specify where users can log in. Define protected resources under the Terminal branch of the Login resource hierarchy to specify where users can log in. Login locations are referred to as terminals in this document. Local and remote terminals: Terminals are either local or remote. Terminals are local when used for logins to a system from serial deices and graphical consoles. Terminals are remote when used across a TCP/IP network. You can group both kinds of terminals together and use inheritance to define access controls. The names of terminal objects follow the format: /OSSEAL/policy-branch/Login/Terminal/Local/termgroup/deice /OSSEAL/policy-branch/Login/Terminal/Remote/termgroup/hostspec 44 IBM Tioli Access Manager for Operating Systems: Administration Guide

61 See Table 14 for definitions of terminal objects. Table 14. Definitions of Terms about Terminals Object name Description Type termgroup deice hostspec An administrator- definable logical grouping of terminals allowing the application of inherited access controls The name of a terminal deice on a system. For example, /de/console or /de/tty/0 The representation of a host, group of hosts, or network. String. This component of the object name must be included. A fully qualified UNIX file name specifying the deice file. No wildcard names are allowed. One of the following: A fully qualified host name from /etc/hosts, DNS, etc. The name can include wildcard characters such as * or? but must always represent a fully qualified name. A simple, short name is not allowed. An IP address/netmask combination in dot notation (IP_address[nbits]). The absence of a specified netmask implies a 32 bit netmask, that is, a host address. Some examples of login resource specifications follow: /OSSEAL/policy-branch/Login/Terminal/Local/Modems/de/tty063 /OSSEAL/policy-branch/Login/Terminal/Remote/Deelopment/*.de.company.com /OSSEAL/policy-branch/Login/Terminal/Remote/Xterms/ :24 Access control on login resources: Attach Tioli Access Manager access controls at the appropriate point in the Login/Terminal object hierarchy to control resources. For example, you can establish a default policy controlling system access from remote locations by attaching an ACL or a POP to the /OSSEAL/policybranch/Terminal/Remote object. Table 15 shows the permission required. Table 15. Valid Permission to Log In Permission Name Login (L) Description Permission from the associated terminal Uniqueness of terminal resources definitions: A terminal can appear in only one terminal group within each policy branch. If a terminal appears in more than one group, a warning is generated in the pdosd error log. The preailing policy authorization is undefined. You might not get the expected results. Chapter 2. Policy 45

62 Login actiity policy Tioli Access Manager for Operating Systems proides the ability to define and enforce policy related to login actiity. The policy is defined centrally by using extended attributes of the /OSSEAL/policy-branch/Login object and controls the following aspects of login actiity: Password expiry Account suspensions due to failed login attempts Account lockouts due to account inactiity The status of each user account is recorded on a per-machine basis. Accounts become locked or suspended only on the machine on which they hae been actie or on which failed login attempts hae occurred. Password expiry times are maintained on a per-machine basis. Tioli Access Manager for Operating Systems login actiity policy is applied in addition to any such policy proided natiely by the operating system. The more restrictie between the Tioli Access Manager for Operating Systems policy and the operating system policy will apply. The system files $HOME/.rhosts and /etc/hosts.equi should not be used when login actiity policy is configured. The behaior of the system with these files in use is platform dependent. For instance, on AIX systems, the use of these system files, in conjunction with the authentication methods that use these files, such as rlogin, and rsh, can result in the complete circumention of the login actiity policy proided by Tioli Access Manager for Operating Systems. Other login policy, such as terminal, time of day, and holiday, is enforced as expected. There is no integration between the password policy specified in the Tioli Access Manager user registry for Tioli Access Manager users and the password expiry implemented by Tioli Access Manager for Operating Systems for natie system accounts. Table 16 describes the extended attributes that control login actiity policy. Table 16. Login Actiity Policy Attributes Login Actiity Attribute Description Type Login-MinPasswordDays Login-MaxPasswordDays Minimum amount of time before a password can be changed. If not specified, a default alue of zero is used indicating that the password may be changed as frequently as a user likes. Maximum amount of time before a password must be changed. If not specified, the default alue of zero is assumed and the passwords will neer be considered to hae expired. After a user s password has expired, the user must change it on the next login unless grace logins are enabled. Grace logins are enabled by setting the Login-MaxGraceLogins attribute to a non-zero alue. Non-negatie integer Non-negatie integer 46 IBM Tioli Access Manager for Operating Systems: Administration Guide

63 Table 16. Login Actiity Policy Attributes (continued) Login Actiity Attribute Description Type Login-MaxGraceLogins Login-MaxConcurrent Login-MaxInactieDays Number of times a user can login after the user s password has expired. If not specified, a default alue of zero is assumed and the user is not permitted to login unless the password is changed. If the maximum number of grace logins is exceeded, the account will be locked permanently. Maximum number of terminals that can be logged in from concurrently by a specific user. Multiple logins from the same terminal count as a single login. A terminal is defined as a remote IP address or the local host. If a alue is set for the default user, then the policy is applied to all users on a system. If not specified, a default alue of zero is used indicating that there is no limit to the number of terminals from which a user can login. The number of days before an inactie account is locked permanently. An account is considered inactie from the last time a successful login occurred to that account. If not specified, the default alue of zero is assumed and inactie accounts are neer locked. Non-negatie integer Non-negatie integer Non-negatie integer Chapter 2. Policy 47

64 Table 16. Login Actiity Policy Attributes (continued) Login Actiity Attribute Description Type Login-MaxFailedLogins Login-LockMinutes Login-LoginMinutes Number of failed login attempts on an account before that account is suspended. The account is suspended for a period of time as determined by the alue of the Login-LockMinutes attribute. The period of time oer which the failed login attempts are counted is determined by the Login-LoginMinutes attribute. If the Login-MaxFailedLogins attribute is not specified, the default alue of zero is assumed and the account will neer be suspended due to failed login attempts. The period of time in minutes to suspend an account when the maximum number of failed logins is reached, as determined by the Login-MaxFailedLogins attribute. If the Login-LockMinutes attribute is not specified, the default alue of zero is assumed indicating the account will remain permanently suspended. The period of time in minutes oer which failed login attempts are counted towards the maximum number of failed login attempts as set in the Login-MaxFailedLogins attribute. If the Login-LoginMinutes attribute is not specified, the default alue of zero is assumed indicating there is no time limit. All inalid login attempts while the account is not locked or suspended count towards the maximum number of failures. Non-negatie integer Non-negatie integer Non-negatie integer 48 IBM Tioli Access Manager for Operating Systems: Administration Guide

65 Table 16. Login Actiity Policy Attributes (continued) Login Actiity Attribute Description Type Login-PolicyDisabled Used to disable all login actiity policy. If this attribute is present and the alue is a non-empty string, then none of the defined login actiity policy is enforced. Non-empty string Examples of login actiity policy: actiity policy. The following are examples of setting login To set accounts to be locked after 30 days of inactiity, you could use the pdadmin command: pdadmin> object modify /OSSEAL/Serers/Login set attribute Login-MaxInactieDays 30 To allow only three failed login attempts in any one hour before suspending an account for 30 minutes, you could use the pdadmin command: pdadmin> object modify /OSSEAL/Serers/Login set attribute Login-MaxFailedLogins 3 pdadmin> object modify /OSSEAL/Serers/Login set attribute Login-LockMinutes 30 pdadmin> object modify /OSSEAL/Serers/Login set attribute Login-LoginMinutes 60 The login actiity policy attributes all use single alues. When modifying an attribute, you must first remoe the existing attribute alue. For example, to change the Login-MaxFailedLogins attribute to 5: pdadmin> object modify /OSSEAL/Serers/Login delete attribute Login-MaxFailedLogins pdadmin> object modify /OSSEAL/Serers/Login set attribute Login-MaxFailedLogins 5 Use the pdoslpadm command to determine the state of an account or to unlock it. See pdoslpadm on page 245 for details on performing this task. User exception policy The user exception policy allows you to define exceptions to the default login actiity policy. This capability is proided strictly as a mechanism to define exceptions to the default policy and should not be used to define login actiity policy for a large number of users. The user exception policy is defined by setting the login actiity extended attributes on the /OSSEAL/policy-branch/Login/UserExceptions/user-name object. Only attributes that are explicitly set for this object apply to the user. Any login actiity extended attribute not explicitly set is gien a alue of zero. These unspecified attributes do not inherit the alue from the default login actiity extended attributes. The user exception policy cannot be specified as a task from the Tioli desktop. Exceptions can only be made using the pdadmin command. Examples of user exception policy The following demonstrates how to set user exception login policy for the policy-branch Default. Chapter 2. Policy 49

66 1. To set the default login actiity policy to hae user accounts set to inactie after 30 days of inactiity and to oerride this default policy for user bob to hae all the login policy attributes set to 0 (disabling policy enforcement), use the following pdadmin commands: pdadmin> object modify /OSSEAL/Default/Login set attribute Login-MaxInactieDays 30 pdadmin > object create /OSSEAL/Default/Login/UserExceptions/bob yes "" 2 i 2. Extending the aboe example, to set bob s account to inactie state after 90 days of inactiity, you could use the following pdadmin command: pdadmin > object modify /OSSEAL/Default/Login/UserExceptions/bob Login-MaxInactieDays 90 set attribute 3. All the login attribute alues use single alues, so to reset the inactiity period for bob in the aboe example to 70, use the following pdadmin commands: pdadmin > object modify /OSSEAL/Default/Login/UserExceptions/bob delete attribute Login-MaxInactieDays pdadmin > object modify /OSSEAL/Default/Login/UserExceptions/bob set attribute Login-MaxInactieDays 70 Password management policy Tioli Access Manager for Operating Systems proides the ability to define and enforce policy related to password management. Password management preents users from specifying weak passwords that are ulnerable to compromise by methods such as a dictionary attack. The policy is defined centrally by using extended attributes of the /OSSEAL/policy-branch/Password object and controls the following aspects of password management actiity: Password strength Password aging Tioli Access Manager for Operating Systems password management policy is applied in addition to any such policy proided natiely by the operating system. The more restrictie between the Tioli Access Manager for Operating Systems policy and the operating system policy will apply. It is possible that the password will be modified by the natie operating system prior to the Tioli Access Manager for Operating Systems password enforcement modules seeing the password. If this happens, the password management policy will be applied to the modified password. For example, if the operating system truncates the password to the number of characters it considers significant, the password management policy is applied to the truncated password. Note: Tioli Access Manager for Operating Systems currently limits the maximum number of significant bytes in a password to 34 bytes. The status of each user account is recorded on a per-machine basis. Password history checks only password changes that hae occurred locally on the machine. The system files $HOME/.rhosts and /etc/hosts.equi should not be used when password management policy is configured. There is no integration between the password policy specified in the Tioli Access Manager user registry for Tioli Access Manager users and the password expiry implemented by Tioli Access Manager for Operating Systems for natie system accounts. Table 17 on page 51 describes the extended attributes that control password management policy. 50 IBM Tioli Access Manager for Operating Systems: Administration Guide

67 Note: An administrator is not subject to the MinPasswordDays check when changing another user s password. In addition, after an administrator changes a user s password, the user will be able to change the password once without the MinPasswordDays check being enforced. Table 17. Password Management Policy Attributes Login Actiity Attribute Description Type Password-MinPasswordLen Password- MinPasswordAlpha Password- MinPasswordAlphaNum Password- MinPasswordNumeric Password- MinPasswordLower Password- MinPasswordUpper Password- MinPasswordSpecial Password-MinPasswordDays Minimum allowed length of a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of alphabetic characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of alphanumeric characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of numeric characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of lower case characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of upper case characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum number of special characters required in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Minimum amount of time before a password can be changed. If a not specified, a default alue of zero is used, indicating that the password can be changed as frequently as a user wants. Non-negatie integer Non-negatie integer Non-negatie integer Non-negatie integer Non-negatie integer Non-negatie integer Non-negatie integer Non-negatie integer Chapter 2. Policy 51

68 Table 17. Password Management Policy Attributes (continued) Login Actiity Attribute Description Type Password- MaxPasswordRepeat Password- PasswordNameCheck Password-PasswordHistory Password- PasswordOldPwdCheck Password- PasswordMaxConsPre Password- PasswordNonNumFirstLast Maximum number of times a character can be repeated consecutiely in a password. If not specified, a default alue of zero is used, indicating that there is no restriction. Check that the password is not contained in and does not contain the user ID. If not specified, a default alue of zero is used, indicating that the user ID can be used in the password. The number of passwords to store as a history. When a new password is set, it cannot be one of these preious passwords. A limited number of history elements will be supported. The maximum alue of the password history is 10. If not specified, a default alue of zero is used, indicating that there is no restriction. Compares the new password with the old one and erifies that the new password is not contained in and does not contain the preious password. If set, this alue is the maximum number of consecutie characters that can be in common between the new password and the old password. If set, this attribute checks that the first and last characters of the password are non-numeric. Non-negatie integer 0 or 1 Non-negatie integer 0 or 1 Non-negatie integer 0 or 1 Examples of password management policy The following are examples of setting password management policy. To deny a password change if the password contained fewer than seen characters, you could use the pdadmin command: pdadmin> object modify /OSSEAL/Serers/Password set attribute Password-MinPasswordLen 7 To allow no repeated characters in a password, you could use the pdadmin command: pdadmin> object modify /OSSEAL/Serers/Password set attribute Password-MaxPasswordRepeat 1 52 IBM Tioli Access Manager for Operating Systems: Administration Guide

69 The password management policy attributes all use single alues. When modifying an attribute, you must first remoe the existing attribute alue. For example, to change the Password-PasswordHistory attribute to 5: pdadmin> object modify /OSSEAL/Serers/Password delete attribute Password-PasswordHistory pdadmin> object modify /OSSEAL/Serers/Login set attribute Password-PasswordHistory 5 Use the pdoslpadm command to determine the state of an account or to unlock it. See pdoslpadm on page 245 for details on performing this task. Examples of user exception policy The following demonstrates how to set user exception password policy for the policy-branch Default. 1. To set the default password policy to hae user password changes denied because the passwords were fewer than 10 characters long and to oerride this default policy for user bob to hae all the password policy attributes set to 0 (disabling policy enforcement), use the following pdadmin commands: pdadmin> object modify /OSSEAL/Default/Password set attribute Password-MinPasswordLen 10 pdadmin > object create /OSSEAL/Default/Password/UserExceptions/bob "" 2 i yes 2. Extending the aboe example, to set bob s account to deny passwords fewer than 5 characters long, you could use the following pdadmin command: pdadmin > object modify /OSSEAL/Default/Password/UserExceptions/bob attribute Password-MinPasswordLen 5 3. All the login attribute alues use single alues, so to reset the minimum password character length for bob in the aboe example to 8, use the following pdadmin commands: pdadmin > object modify /OSSEAL/Default/Password/UserExceptions/bob attribute Password-MinPasswordLen set delete pdadmin > object modify /OSSEAL/Default/Password/UserExceptions/bob attribute Password-MinPasswordLen 8 set Surrogate policy Tioli Access Manager for Operating Systems proides the ability to control operations that can change the UNIX identity of a process. Such operations are referred to as surrogate operations and are controlled by resources of type Surrogate. Surrogate operations can change the user identity or group identity of a process. Access control of each of these kinds of surrogate operations is established by applying authorization policy to the User and Group sub-types of the Surrogate resource type. The object names identify the potential targets of surrogate operations and control the ability, for example, to surrogate to the root user or the system group. Surrogate resource names follow the form: /OSSEAL/policy-branch/Surrogate/User/user-name /OSSEAL/policy-branch/Surrogate/Group/group-name Chapter 2. Policy 53

70 Table 18 details the surrogate objects presented aboe. Table 18. Surrogate Object Naming Object Name Description Type user-name group-name A UNIX user name. Attempts to change identity to this user are protected by the access controls applied to this object. A UNIX group name. Attempts to change identity to this group are protected by the access controls applied to this object. String representing the UNIX user name. Numeric user IDs are not accepted. String representing the UNIX group name. Numeric group IDs are not accepted. Example surrogate resources Some example surrogate resource specifications are gien below: /OSSEAL/Default/Surrogate/User/root /OSSEAL/Default/Surrogate/User/joe /OSSEAL/Default/Surrogate/Group/admin Note: The application of access controls to the /OSSEAL/policybranch/Surrogate/User, the /OSSEAL/policy-branch/Surrogate/Group objects, or the containing /OSSEAL/policy-branch/Surrogate object itself allows the definition of default Surrogate policy. See the Considerations for establishing surrogate policy for warnings about the implications of establishing Surrogate policy that is restrictie. No wildcards can be used for Surrogate resources. The only permission used to control access to Surrogate resources is the Surrogate (G) permission as shown in Table 19. Table 19. Surrogate Operation Permission Permission Name Description G Surrogate Permission to perform a user or group surrogate operation. Considerations for establishing surrogate policy Surrogate operations occur in two fundamentally different ways: A running program, in the course of its execution, might change user or group identity. A program with either or both of the set user ID or set group ID UNIX file permissions set will change identity on execution The distinction is important. Programs that hae the set user ID or set group ID permission set are generally intended to be run by unpriileged users who need to perform tasks that temporarily require more priileges than users would normally hae. Such programs are trusted to perform only prescribed operations while running with this eleated priilege. Typical examples, depending on the platform, include programs like /usr/bin/mail, /usr/bin/telnet, and /usr/bin/ps. Assume these programs are all setuid root. If you restrict the ability of general users to surrogate to root, then they will no longer be able to run these programs. These programs are trusted to perform a limited set of operations while they are executing with eleated priilege. Tioli Access Manager for Operating Systems 54 IBM Tioli Access Manager for Operating Systems: Administration Guide

71 lets you define them as part of a Trusted Computing Base so that surrogate operations performed when a program is executed occur without requiring an authorization decision. Programs defined as Secure-Programs under the Trusted Computing Base resource type are permitted to change their user or group identity on execution without being subject to Surrogate authorization policy. See Trusted Computing Base resources on page 30. If such a program performs subsequent surrogate operations after the program has been executed, then these operations are subject to Surrogate authorization policy. Consider the /usr/bin/su command. This command lets a user who knows the password of another user, explicitly change to that user s identity. UNIX security requires that only the root user is allowed to change user identity, therefore, the su command is set up on all UNIX systems as a setuid root program. If the su command were not made a Secure-Program in the Tioli Access Manager for Operating Systems Trusted Computing Base, then een users who are authorized to surrogate to other non-root users would require the ability to surrogate to root as well as the user they really want to surrogate to. With the command configured as a Secure-Program, the only Tioli Access Manager for Operating Systems Surrogate authorization policy that is enforced is the one that protects the target user of su. For example, assume user fred is authorized to change identity to the sysop user. When fred runs the su command: fred$ su sysop two surrogate operations occur. The first is a surrogate operation to root as su is a setuid root program. The second occurs when fred correctly enters the sysop account s password and the su command explicitly changes identity to the sysop user. With the su command configured as a Secure-Program fred does not need Tioli Access Manager for Operating Systems authority to surrogate to root, only to sysop. The su command is the only standard UNIX command configured as a Secure-Program by default. Tioli Access Manager for Operating Systems proides the pdosuidprog command to help you locate other setuid and setgid programs that you might want to add as Secure-Programs if you establish restrictie Surrogate policy. See pdosuidprog on page 271 for details of running this command. If you establish restrictie Surrogate policy and add appropriate setuid and setgid programs as Secure-Programs in the Trusted Computing Base you might find that users running these programs still require Surrogate authority to users or groups you did not anticipate. The programs might be performing surrogate operations after they are executed. If this is the case and you do not wish to proide open access to these restricted user and group identities, then you can use Access-Restrictions to permit users to execute these surrogate operations only when running particular programs. Access restrictions on page 14 explains how such a policy may be defined. When a UNIX user successfully executes a surrogate operation, the accessor identity that applies to Tioli Access Manager for Operating Systems authorization decisions does not change. A surrogate operation cannot be used by a user to change the user s identity. A second class of Trusted Computing Base programs, Impersonator-Programs, allows surrogate operations to change the IBM Tioli Chapter 2. Policy 55

72 Access Manager for Operating Systems accessor identity as well as the UNIX user identity of the process. See Trusted Computing Base resources on page 30 for more information about the Impersonator-Programs class of TCB resources Access Control on Surrogate Resources The authorization policy associated with surrogate resources is expressed by attaching Tioli Access Manager ACLs to the user name or group name objects. In addition, default surrogate policy for users and groups can be defined by attaching Tioli Access Manager ACLs to the User or Group container objects and employing ACL inheritance. Also, attaching an ACL to the Surrogate container object imposes default surrogate permissions for all users and groups (assuming the user and group containers do not hae explicitly attached ACLs). The Tioli Access Manager traerse (T) permission is also employed as part of the access control decision. Table 19 on page 54 details the alid ACL permissions that may be associated with surrogate resources. Sudo Policy Sudo resources describe commands that require more stringent access control than whether or not a particular program can be executed. Sudo commands allow access control based not only on a command but also on the parameters passed to that command. You can use Sudo commands to remoe the requirement for a user to become the root user on a system in order to perform administratie tasks. Sudo does this by proiding the capability to execute a command as a UNIX user other than that of the inoker. Sudo resources are identified in the Tioli Access Manager namespace in the following way: /OSSEAL/policy-branch/Sudo/sudo-command[/sudo-argclass] The attributes of the Sudo command are listed in Table 20. Table 20. Sudo Objects Object Name Description Type sudo-command sudo-argclass The name of the Sudo command. This is the object with which parameters describing the actual program, UNIX user identity, and password are associated. You specify this name. The name of a class of command arguments. The administrator chooses this name. String representing a Sudo command. String representing a Sudo argument class. Define the attributes of a Sudo command by creating an object that identifies the Sudo command. Set the Sudo command extended attributes on the object to the appropriate alues. Table 21 on page 57 lists the command attributes. 56 IBM Tioli Access Manager for Operating Systems: Administration Guide

73 Table 21. Sudo Command Attributes Extended Attribute Description Type Sudo-Command Sudo-Target-User Sudo-Inoker-Password Sudo-Target-Password The program to run when access to the Sudo command is granted. This parameter must be specified for Tioli Access Manager for Operating Systems to consider the Sudo object as alid. This attribute uses a single alue. The UNIX user name under which the program specified by the Sudo-Command is run. This UNIX user must exist on eery system on which the Sudo command needs to run. This attribute is optional. The default alue is root. This attribute uses a single alue. This attribute indicates that the inoker of the Sudo command must enter a password before the command can be executed. The default is to not require the inoker s password. This attribute uses a single alue. This attribute indicates that the inoker of the Sudo command must enter the password of the target user specified by the Sudo-Target-User attribute before the command can be executed. The default is to not require the inoker to supply the target user s password. This attribute uses a single alued. A fully qualified UNIX file name specifying the program. The string can be a simple UNIX file name, such as /usr/bin/mount, or contain a fixed set of arguments, for example, /usr/bin/rm -i. The arguments specified must be separated by a space and cannot contain any quotation marks. A string representing the name of the UNIX user. The alue must be a non-empty string. The alue must be a non-empty string. The execute (x) permission is required to execute a Sudo command as shown in Table 22. Table 22. Permission Required for Sudo Permission Code Permission Name Permission Granted x Execute Execute the Sudo command Chapter 2. Policy 57

74 An example of Sudo usage To define a Sudo command that allows only members of the sys-admin group to use the /usr/sbin/mount system program and that requires the inoker to enter a password when running the command, you can use the following pdadmin commands: pdadmin> object create /OSSEAL/Serers/Sudo/mount "mount" 2 \ ispolicyattachable yes pdadmin> object modify /OSSEAL/Serers/Sudo/mount set attribute \ Sudo-Command /usr/sbin/mount pdadmin> object modify /OSSEAL/Serers/Sudo/mount set attribute \ Sudo-Inoker-Password "required" pdadmin> acl create sudo-mount pdadmin> acl modify sudo-mount set group sys-admin T[OSSEAL]x pdadmin> acl attach /OSSEAL/Serers/Sudo/mount sudo-mount You can control what arguments might be proided by defining a Sudo argument class object subordinate to the Sudo command object. Sudo argument class objects are defined in a similar manner to Sudo command objects by defining extended attributes of the Sudo argument class object. The extended attribute that is used to define a Sudo argument class is defined in Table 23. Table 23. Extended Sudo Attributes for Fine-grained Control Extended Attribute Description Type Sudo-Arguments A wildcard string used to match command line arguments. This attribute is multi-alued allowing multiple patterns to describe a single argument class. There is no default alue. A wildcard string used to match command line arguments. To continue the example, to allow members of the group net-admin to mount NFS file systems and only members of the group sys-admin to mount local file systems use the following pdadmin commands in addition to the ones aboe: pdadmin> object create /OSSEAL/Serers/Sudo/mount/remote \ "Remote mount argument patterns" 0 ispolicyattachable yes pdadmin> object modify /OSSEAL/Serers/Sudo/mount/remote set attribute \ Sudo-Arguments "[-]F nfs" pdadmin> acl create sudo-net-mount pdadmin> acl modify sudo-net-mount set group net-admin T[OSSEAL]x pdadmin> acl attach /OSSEAL/Serers/Sudo/mount/remote sudo-net-mount pdadmin> object create /OSSEAL/Serers/Sudo/mount/local \ "Local mount argument patterns" 0 ispolicyattachable yes pdadmin> object modify /OSSEAL/Serers/Sudo/mount/local set \ attribute Sudo-Arguments "[-]F *" pdadmin> acl create sudo-local-mount pdadmin> acl modify sudo-local-mount set group sys-admin T[OSSEAL]x pdadmin> acl attach /OSSEAL/Serers/Sudo/mount/local sudo-local-mount pdadmin> acl modify sudo-mount set group sys-admin "" An explanation of this example: The following notes help explain this example: When setting an attribute alue in pdadmin, the alue may not start with a dash character. The dash is represented as [ ], a character range containing only a hyphen (-) The policy aboe relies on the precedence of the wildcard patterns. The [-]F nfs pattern is more specific than the [-]F * pattern. The sys-admin group entry in the sudo-mount ACL attached to /OSSEAL/Serers/Sudo/mount was cleared. This preents users from accessing the mount Sudo command unless they specify a F parameter as the first option. 58 IBM Tioli Access Manager for Operating Systems: Administration Guide

75 To accommodate the slightly different syntaxes of the mount command on different platforms, you can make the wildcard expressions more complex. For example, mount might expect the t option instead of the F option in order to specify the file system type, or NFS might be accepted in place of nfs. To accommodate two cases, the alue of the Sudo-Arguments attribute of the /OSSEAL/Serers/Sudo/mount/remote object can be replaced with [-][tf] [Nn][Ff][Ss]. If the same pattern appears in two different Sudo argument classes of the same Sudo command, warning messages identifying the ambiguous policy are generated in the pdosd daemon s log file and an administratie audit eent is generated. The messages do not define which, if any, of the ambiguous policies is applied. This syntax of UNIX commands can be ery complex, allowing specification of command line options and parameters in any order and combination. This can make it difficult to define argument patterns that coer all possibilities. By defining a default behaior that denies access to the Sudo command, the combinations and order of command-line options can be restricted to a manageable set. l Wildcards in Sudo arguments The Sudo-Arguments attribute uses IBM Tioli Access Manager for Operating Systems wildcards in a manner similar to the other resource types. The basic elements of the Sudo-Arguments wildcard strings are the same as the other wildcards with the following exceptions: The wildcard asterisk (*) matches a sequence of non-white space characters rather than a sequence of any characters. The asterisk matches an entire command line argument rather than the entire command line. For example, the following pattern matches an arbitrary string as the first argument followed by the string root as the second argument: * root If the second argument is not root, this pattern does not match. A single-space character in the pattern matches any sequence of white-space characters in the string being matched. The special meaning of the space character can be escaped with a backslash character (\), in which case it matches only one space. If the Sudo-Arguments attribute has the alue, then this matches the empty string and allows the definition of a pattern that matches when no arguments are passed to the Sudo command. The pattern matches a string een if there are trailing arguments that were not matched by the pattern, as long as the preceding arguments matched the entire pattern. For example the pattern: * root matches both of the strings: show root add root system The pdossudo command Inoke Sudo commands by entering the pdossudo command and specifying the Sudo command name and any arguments. In An example of Sudo usage on page 58, the mount Sudo command would be inoked as follows: Chapter 2. Policy 59

76 $ pdossudo mount F nfs host:/shared/directory /local The authorization process of a Sudo command proceeds in this order: 1. Determining whether the inoking user has execute permission on the requested Sudo command, or Sudo argument class if the arguments specified on the command line match an argument. 2. If they match, the inoking user is prompted for the required passwords, if any. 3. If all required passwords are entered correctly, then the effectie UNIX user ID of the process is changed to that of the target user. This identity change is subject to Surrogate policy so the inoking user must hae authority to Surrogate to the target user (this Surrogate authority can be restricted by using an Access-Restrictions attribute in order to only permit users to Surrogate when inoking the pdossudo command). Such Surrogate policy should be applied with care as it will affect all Surrogate authorization decisions. 4. The Sudo command is executed only after all of these operations hae completed successfully with the specified arguments. You might also want to establish an Access-Restrictions attribute on the program specified in the Sudo-Command attribute, restricting execution of this program to the pdossudo command. The following pdadmin commands show how these Access-Restrictions might be established: pdadmin> object create /OSSEAL/Serers/Surrogate/User/root \ "surrogate root" 14 ispolicyattachable yes pdadmin> acl create root-user pdadmin> acl modify root-user set any-other T[OSSEAL]G pdadmin> acl modify root-user set unauthenticated T[OSSEAL]G pdadmin> acl modify root-user set attribute \ Access-Restrictions any-other:g:/opt/pdos/bin/pdossudo pdadmin> acl modify root-user set attribute \ Access-Restrictions unauthenticated:g:/opt/pdos/bin/pdossudo pdadmin> acl attach /OSSEAL/Serers/Surrogate/User/root root-user pdadmin> object create /OSSEAL/Serers/File/usr/bin/mount \ "mount command" 3 ispolicyattachable yes pdadmin> acl create mount-program pdadmin> acl modify mount-program set any-other T[OSSEAL]x pdadmin> acl modify mount-program set unauthenticated T[OSSEAL]x pdadmin> acl modify mount-program set attribute \ Access-Restrictions any-other:x:/opt/pdos/bin/pdossudo pdadmin> acl modify mount-program set attribute \ Access-Restrictions unauthenticated:x:/opt/pdos/bin/pdossudo pdadmin> acl attach /OSSEAL/Serers/File/usr/bin/mount mount-program The pdossudo command is the only way to change identity to the root user with this policy in place and the only way to execute the mount command. In order to protect Sudo commands from being tricked when a user sets enironment ariables with the priilege of another UNIX user, the enironment isible to the executed Sudo program is tightly controlled. An example of such a trick attempt is to change the PATH to alues that would allow execution of inappropriate programs. Table 24 on page 61 shows the enironment ariables that are stripped from the user s enironment before the Sudo command is executed: 60 IBM Tioli Access Manager for Operating Systems: Administration Guide

77 Table 24. Enironment Variables Stripped by Sudo Enironment Variable PATH LD_* _RLD_* SHLIB_PATH LIBPATH IFS ENV BASH_ENV KRB_CONF KRB5_CONFIG LOCALDOMAIN RES_OPTIONS HOSTALIASES Notes The command location path All shared library search path enironment ariables beginning with LD_ All runtime linker enironment ariables beginning with _RLD_ HP-UX only, the shared library search path AIX only, the shared library search path The input field separator Enironment file location Bash enironment file location Kerberos 4 configuration file location Kerberos 5 configuration file location Oerride for domain name in /etc/resol.conf Options for host name resolution Oerride for location of host alias specification file Specify the alues for these or other enironment ariables by defining them in the pdossudo configuration file: /opt/pdos/etc/pdossudo.conf. Enironment ariables are specified by defining them in the [enironment] stanza of the file (this is the only stanza in the file). For example, a suitable pdossudo.conf configuration alue for including an application s commands and shared libraries in the appropriate search path might be: [enironment] PATH=/usr/bin:/usr/sbin:/usr/application/bin LD_LIBRARY_PATH=/usr/lib:/usr/application/lib When the Sudo command is executed, the PATH and LD_LIBRARY_PATH enironment ariables will be set according those specified in the pdossudo.conf configuration file. The pdossudo command also sets enironment ariables to permit scripts to identify the inoker of the command. They are defined in Table 25. Table 25. Enironment Variables Set by Sudo Enironment Variable PDOS_SUDO_ACCESSOR_NAME PDOS_SUDO_ACCESSOR_ID PDOS_SUDO_INVOKER_NAME Description The user name corresponding to the Tioli Access Manager accessor ID of the user inoking the Sudo command. The numeric ID corresponding to the Tioli Access Manager accessor ID of the user inoking the Sudo command. The user name corresponding to the UNIX user that inoked the pdossudo command. This might differ from the accessor name if an identity change occurred after login, for example, if the user executed the su command. Chapter 2. Policy 61

78 Table 25. Enironment Variables Set by Sudo (continued) Enironment Variable PDOS_SUDO_INVOKER_ID Description The numeric ID corresponding to the UNIX user that inoked the pdossudo command. This might differ from the accessor name if an identity change occurred after login, for example, if the user executed the su command. Audit resources This section describes the user-leel audit policy resources as they are defined in the Tioli Access Manager for Operating Systems enironment. It describes how to set user-leel audit policy for authorization decisions and trace. Audit authorization resources Tioli Access Manager for Operating Systems proides the ability to control, which UNIX users or Tioli Access Manager group members generate, audit records for authorization decisions. A special case is allowed to specify policy for those UNIX users who are unauthenticated in the Tioli Access Manager user registry. User-leel audit policy specifies additional audit policy besides that which is already proided through global auditing or resource leel auditing. It also proides the ability to turn off auditing for specific users or groups. User-leel audit authorization resources are represented in the Tioli Access Manager namespace by defining an object name with a resource type of AuditAuth. Attaching an ACL or POP to these resources has no effect. They are represented as: /OSSEAL/policy-branch/AuditAuth/Unauth/audit-leel /OSSEAL/policy-branch/AuditAuth/User/user-name/audit-leel /OSSEAL/policy-branch/AuditAuth/Group/group-name/audit-leel Table 26. User-leel audit authorization objects Object Name Description Type user-name A UNIX user name. String representing the UNIX user name. group-name A Tioli Access Manager group name. String representing the group in the Tioli Access Manager User Registry. 62 IBM Tioli Access Manager for Operating Systems: Administration Guide

79 Table 26. User-leel audit authorization objects (continued) Object Name Description Type audit-leel The audit leel for the specified user or group. String alue must be one the following: permit: Audit all authorization decisions that permit access to a protected resource by this user. deny: Audit all authorization decisions that deny access to a protected resource by this user. loginpermit: Audit all login authorization decisions that permit the login by the user. logindeny: Audit all login authorization decisions that deny the login by this user. all: none: Audit all authorization decisions for this user. (permit, deny, loginpermit, and logindeny) Do not audit any authorization decisions for this user. This oerrides all global audit or resource audit settings for this user. This also oerrides any other audit-leel specifications that apply to this user. There may be more than one resource specification for a user or group. The following rules apply: 1. User resource definitions always oerride the Unauth resource definition and any group resource definitions that apply to the user. If one or more user resource definitions exist for a specific user, only those definitions apply to that user. Any group definitions for groups that the user is a member of are ignored. 2. If a user resource definition specifies a leel of none, this oerrides any other entries for the user. 3. If a user is a member of more than one group with group resource definitions, the policy that is applied will be the union of the group entries. 4. If a user is a member of a group where a resource definition specifies a leel of none, this oerrides any other group entries that apply to the user. Example audit authorization resources /OSSEAL/Default/AuditAuth/User/root/all /OSSEAL/Default/AuditAuth/Unauth/all /OSSEAL/Default/AuditAuth/Group/osseal-admin/permit /OSSEAL/Default/AuditAuth/Group/osseal-admin/deny /OSSEAL/Default/AuditAuth/User/admin1/loginpermit Examples of audit authorization usage To set up policy so that all authorization decisions made on behalf of members of the osseal-admin group are audited for the policy-branch Serers, use the following pdadmin command: Chapter 2. Policy 63

80 pdadmin> object create /OSSEAL/Serers/AuditAuth/Group/osseal-admin/all "AuditAuth" 11 ispolicyattachable no To set up policy so that all login decisions made on behalf of the root user are audited, use the following pdadmin commands: pdadmin> object create /OSSEAL/Serers/AuditAuth/User/root/loginpermit "AuditAuth" 11 ispolicyattachable no pdadmin> object create /OSSEAL/Serers/AuditAuth/User/root/logindeny "AuditAuth" 11 ispolicyattachable no To set up policy so that all authorization decisions made on behalf of members of the osseal-admin group, except the root user, are audited, use the following pdadmin commands: pdadmin> object create /OSSEAL/Serers/AuditAuth/Group/osseal-admin/all "AuditAuth" 11 ispolicyattachable no pdadmin> object create /OSSEAL/Serers/AuditAuth/User/root/none"AuditAuth" 11 ispolicyattachable no To set up policy so that all authorization decisions that permit access to protected resources are audited and any authorization decisions that deny access by the root user are audited, turn on global auditing and use the following pdadmin command: pdoscfg audit_leel permit pdadmin> object create /OSSEAL/Serers/AuditAuth/User/root/deny "AuditAuth" 11 ispolicyattachable no Audit trace resources Tioli Access Manager for Operating Systems proides the ability to control, which UNIX users generate, trace records. User-leel audit trace policy specifies additional audit policy besides that which is already proided through global auditing. It also proides the ability to turn off tracing for specific users. User-leel audit trace resources are represented in the Tioli Access Manager namespace by defining an object name with a resource type of AuditTrace. Attaching an ACL or POP to these resources has no effect. They are represented as: /OSSEAL/policy-branch/AuditTrace/User/user-name/trace-leel Table 27. User-leel audit trace objects Object Name Description Type user-name A UNIX user name. String representing the UNIX user name. 64 IBM Tioli Access Manager for Operating Systems: Administration Guide

81 Table 27. User-leel audit trace objects (continued) Object Name Description Type trace-leel The trace leel for the specified user. String alue must be one of the following: exec: Trace all program inocations initiated by exec() that occur in processes that descend from a login eent that was detected by Tioli Access Manager for Operating Systems for this user. exec_l: Trace all program inocations inititated by exec() that occur in processes that descend from a login eent that was detected by Tioli Access Manager for Operating Systems for this user when the accessing user s identity is different than the user s effectie user identity (which typically happens when a user surrogates to another user). file: Traces all accesses to protected files by this user. Tracing only occurs for those processes that descend from a login eent that was detected by Tioli Access Manager for Operating Systems. all: Trace all exec, exec_1, and file for this user. none: Don't trace anything for this user. This oerrides the global audit setting. This also oerrides any other trace-leel specifications that apply to this user. A maximum of 1024 AuditTrace users are allowed. AuditTrace policy for additional users will not be enforced. /OSSEAL/Default/AuditTrace/User/root/exec_l /OSSEAL/Default/AuditTrace/User/admin1/exec /OSSEAL/Default/AuditTrace/User/admin2/exec Example audit trace resources To set up policy so that trace exec audit records are generated when the accessor ID is root for the policybranch serers, use the following pdadmin command: pdadmin> object create /OSSEAL/Serers/AuditTrace/User/root/exec "AuditTrace" 11 ispolicyattachable no To set up policy to generate trace exec audit records when the accessor ID is root but the effectie ID is something different, use the following pdadmin command: pdadmin> object create /OSSEAL/Serers/AuditTrace/User/root/exec_l "AuditTrace" 11 ispolicyattachable no To set up policy to generate trace file records when the accessor ID is root, use the following pdadmin command: pdadmin> object create /OSSEAL/Serers/AuditTrace/User/root/file "AuditTrace" 11 ispolicyattachable no To set up policy so that trace exec audit records are generated when the accessor ID is admin1, admin2 or admin3, use the following pdadmin commands: Chapter 2. Policy 65

82 pdadmin> object create /OSSEAL/Serers/AuditTrace/User/admin1/exec "AuditTrace" 11 ispolicyattachable no pdadmin> object create /OSSEAL/Serers/AuditTrace/User/admin2/exec "AuditTrace" 11 ispolicyattachable no pdadmin> object create /OSSEAL/Serers/AuditTrace/User/admin3/exec "AuditTrace" 11 ispolicyattachable no 66 IBM Tioli Access Manager for Operating Systems: Administration Guide

83 Chapter 3. Runtime Daemons This chapter describes the major components of Tioli Access Manager for Operating Systems and their operating enironment. These components include: The pdosd authorization daemon on page 68 The pdosauditd audit daemon on page 77 The pdoswdd watchdog daemon on page 79 The pdostecd Tioli Enterprise Console daemon on page 81 The pdoslpmd login policy and password management daemon on page 82 The pdoslrd log router daemon on page 83 The following topics are also described in this chapter: Users and groups on page 84 Files and directories on page 87 Initial policy on page 89 Isolated operation on page 93 The daemons responsible for the major functions of Tioli Access Manager for Operating Systems are: pdosd The Authorization Daemon Makes authorization decisions and monitors the Trusted Computing Base. pdosauditd The Audit Daemon Receies audit eents from other components of Tioli Access Manager for Operating Systems and manages the audit trail. pdoswdd The Watchdog Daemon Ensures that the other daemons remain aailable. The other daemons also monitor each other. pdostecd The Tioli Enterprise Console Daemon Makes many of the Tioli Access Manager for Operating Systems audit eents aailable to the Tioli Enterprise Console. pdoslpmd The Login Policy and Password Management Daemon Makes authorization decisions about logins and password changes. pdoslrd The Log Router Daemon Makes audit records aailable for transfer to multiple locations. Each daemon maintains a log file that records significant eents and error conditions. The records written to the log files contain a UTC timestamp, information identifying the component logging the eent, the message classification, and the message text. By default, the log files are not automatically archied and are persistent across restarts of Tioli Access Manager for Operating Systems. You can configure how many log entries can be written to the log file before a new log is started. You can also configure, for each daemon, how many log files to maintain before recycling the files. Copyright IBM Corp. 2000,

84 If log file archie is enabled, when the daemon log file reaches the maximum number of entries, the log file will be archied by appending a period and an archie number to it. For instance, when the msg pdosd.log file is full, it is renamed msg pdosd.log.1 and a new msg pdosd.log file is created. Logging will continue in the msg_pdosd.log file until it is full at which time it will be renamed to msg pdosd.log.2. When the configured number of archie log files is reached, the archie file names will be recycled and the next time the log file is archied it will start from one. For example, if the configured number of archies is two, the next time the msg pdosd.log file is archied, it will be renamed to msg pdosd.log.1. In addition, if log file archie is enabled, each time the daemon is restarted, the existing log file will be archied to the next archie in the sequence and a new log file will be created. If the number of archie log files is zero, but the maximum number of entries is non-zero, the log itself will recycle when it reaches the maximum number of entries or the daemon is restarted. When the configured number of files is used, the files are reused in the order in which they were created. File reuse also occurs when the daemon is stopped and restarted, if rolloer is enabled. When a log file is reused, the existing records are truncated. You can set these and other runtime options with the pdoscfg command. The pdoscfg command modifies the configuration files. These modifications do not take effect until the next time that Tioli Access Manager for Operating Systems is stopped and restarted. You can dynamically change some runtime options while the Tioli Access Manager for Operating Systems daemons are running by using the pdosctl command. Changes made with the pdosctl command take effect immediately and are not persistent when you restart. For more information, see the following: pdoscfg on page 225 lists all the pdoscfg options Tuning the configuration on page 118 shows the mapping between the pdoscfg options and the configuration file attributes described in this chapter pdosctl on page 237 lists all the pdosctl options. The pdosd authorization daemon The authorization daemon, pdosd, does the following: Handles the authorization requests generated by the kernel extension Tioli Access Manager for Operating Systems when it intercepts operations that are subject to policy Maps UNIX user identities to Tioli Access Manager credentials that describe users and their group memberships from a Tioli Access Manager point of iew Monitors the files that constitute the Trusted Computing Base in order to detect any changes that would cause them to become untrusted Credential acquisition The credential acquisition serice is ital to the pdosd daemon s authorization decision process. The UNIX identity and its relationship to the Tioli Access Manager user identity on page 3 discusses at a high leel how a UNIX user s identity is used to obtain a Tioli Access Manager credential required for making an authorization decision. This section describes the lower-leel aspects of this process. In order for Tioli Access Manager to make authorization decisions efficiently and also to ensure its ability to function in isolation from the LDAP user registry, credentials are cached by the pdosd daemon as they are used. The pdosd 68 IBM Tioli Access Manager for Operating Systems: Administration Guide

85 daemon uses an in-memory cache and a disk cache. All credentials are represented in the disk cache. Only actie users hae their credentials aailable in the memory cache. There is one cached credential for each user. Credentials are cached as users log in to the system. Each time a user logs into the system, Tioli Access Manager for Operating Systems retriees a new credential from the LDAP user registry and stores it in the credential cache. That user continues to use the cached credential until a new login operation is detected for that same user. When a new login operation is detected, Tioli Access Manager for Operating Systems again retriees a new credential from the LDAP user registry and replaces the cached credential with the new credential. When the new credential has been cached, any operations performed by that user, from any of the user s login shells, use the newly cached credential until it is replaced or remoed from the cache. Refreshing the credential reflects up any changes in the LDAP user registry of the user s group membership. A user s group membership can change by being added to groups or by being remoed from groups. Changes in group membership are not reflected until a user s credential is refreshed. You can use the pdosrefresh command to force a user s credential to be refreshed without waiting for the user to log in again. Any group membership changes are then reflected immediately. Each cached credential has a refresh time and a hold time associated with it: Refresh time When a credential s refresh time is reached, the pdosd daemon retriees a new credential from the LDAP user registry and replaces the cached credential with the new credential. Hold time When a credential s hold time is reached, the pdosd daemon remoes the credential from the cache. A new credential is retrieed from the LDAP user registry the next time it is needed by the pdosd daemon. Credential acquisition and user type: Systems users are classified as either: General users Administratie users Critical system users Tioli Access Manager for Operating Administratie users are defined as all users who are members of the osseal-admin Tioli Policy Director group and the osseal UNIX group. Administratie users hae the following attributes in addition to those of general users: Credentials of administratie users are neer flushed from the disk cache Credentials of administratie users are maintained on a system een for administratie users that hae neer logged on The default decision made by the pdosd daemon when making a decision under error conditions is to grant access. For general users, the default decision is to deny. Chapter 3. Runtime 69

86 Critical system users are defined by the system administrator as users who are critical to system operation. These users are members of the Tioli Access Manager group specified by the -critical_cred_group option to the pdoscfg command. Critical system users hae the following attributes in addition to those of general users: Credentials of critical system users are neer flushed from the disk cache Credentials of critical system users are maintained on a system een if the users hae neer logged on. The critical cred group is optional and does not need to be configured. It does not need to hae a corresponding local UNIX group. The members of the group must hae corresponding local UNIX IDs or they will be ignored. Table 28 on page 71 lists the configuration attributes pertaining to the IBM Tioli Access Manager for Operating Systems Credential Acquisition Serice in the /opt/pdos/etc/pdosd.conf configuration file. 70 IBM Tioli Access Manager for Operating Systems: Administration Guide

87 Table 28. Tioli Access Manager for Operating Systems Credential Configuration Attributes Stanza Attribute Description [credentials] user-cred-refresh admin-cred-refresh critical-cred-refresh cred-hold critical-cred-group cred-response-wait The number of minutes that user credentials can exist in the credential cache before they are considered due for a refresh. The interal starts at the time the credential is cached. After the refresh interal is exceeded, the credential is refreshed. The frequency of the refresh of the credentials of administratie users. This allows admin user credential refresh periods to be managed independently from those of the general user. It is also specified in minutes. The frequency of the refresh of the credentials of critical system users. This allows the critical user credential refresh periods to be managed independently from those of general users. It is also specified in minutes. The number of minutes that general user credentials may remain in the credential cache beyond the time that they were last accessed. Credentials of general users that remain cached beyond this time will be flushed from the cache. Administratie and critical system credentials are neer flushed from the cache. The cred-hold interal must be at least as long as the user-cred-refresh interal. The name of the Tioli Access Manager group containing all users who are to be treated as critical system users. This group must be created and populated by the system administrator. Credentials for users who are members of this group are neer remoed from the cache. System administrators should use this group to specify users who are critical to the system and programs running on it to function properly. Administratie users (members of the Tioli Access Manager osseal-admin group) do not need to be members of this group. The minimum number of minutes that the pdosd daemon will wait for responses to credential requests from the Tioli Access Manager user registry before entering isolation mode. If Tioli Access Manager for Operating Systems cannot communicate with the Tioli Access Manager user registry when a credential is due to be refreshed, that credential remains in the cache until communication with the user registry is reestablished. During that time the cached credential continues to be used by Tioli Access Manager for Operating Systems. Tioli Access Manager for Operating Systems and the Tioli Access Manager user registry: Tioli Access Manager for Operating Systems uses the Tioli Access Manager Runtime Enironment configuration for locating and communicating with the user registry. This enables Tioli Access Manager for Operating Systems to share the user registry configuration with other components of Tioli Access Manager, for example the location of user registry replicas. See the IBM Tioli Access Manager Base Administrator s Guide for details on configuring the Tioli Chapter 3. Runtime 71

88 Access Manager Runtime Enironment. Tioli Access Manager for Operating Systems supports only LDAP as the Tioli Access Manager user registry. Table 29 shows the configuration attributes in the pdosd configuration file, /opt/pdos/etc/pdosd.conf, that control the daemon s communications with the user registry. These attributes are established during configuration and should not be modified. Table 29. Configuration Attributes Controlling pdosd s Communications with the User Registry Stanza Attribute Description [ldap] ldap-serer-config ssl-enabled bind-dn bind-pwd Location of the Tioli Access Manager Runtime LDAP configuration file. Boolean flag indicating whether or not to use SSL communications with LDAP. This must be set to enable SSL communications. The distinguished name (DN) that the pdosd daemon uses to authenticate when accessing the LDAP user registry. The password that the pdosd daemon uses to authenticate when accessing the LDAP user registry. Security considerations: The attributes you set affect the security of your system. Be careful when you set or change these settings. The use of SSL to communicate to the LDAP serer allows for mutual authentication between the PDOSD daemon and the LDAP serer. The certificate of the Certification Authority (CA) that signed the LDAP serer s certificate, proided when Tioli Access Manager for Operating Systems was configured, enables the pdosd daemon to erify that the LDAP serer is the real LDAP serer. Because the information proided by the LDAP serer is used by the pdosd daemon, through the Tioli Access Manager runtime, to construct the user credentials used in making authorization decisions, this information must be trusted. Authentication of the LDAP serer by the pdosd daemon allows this leel of trust. See the IBM Tioli Access Manager for Operating Systems Installation Guide. Other sensitie information contained here is the DN and password used by the pdosd daemon to authenticate itself to the LDAP user registry. Just as the pdosd daemon must trust its source of information for constructing credentials, the LDAP serer must allow only legitimate access that information. Note: The password (bind-pwd) no longer appears in the pdosd.conf file. It is stored in an obfuscated file named /opt/pdos/etc/pdosd.conf.obf and is specified in a stanza entry in the pdosd.conf file as follows: [configuration-database] file = /opt/pdos/etc/pdosd.conf.obf To protect this information, the default policy established by Tioli Access Manager for Operating Systems attaches the osseal-restricted ACL to the /opt/pdos/etc directory, which contains the Tioli Access Manager for Operating Systems configuration files. This ACL permits access to only administratie users, that is, members of the osseal-admin group. 72 IBM Tioli Access Manager for Operating Systems: Administration Guide

89 Authorization decision process The pdosd daemon is a local-mode Tioli Access Manager Authorization API application. The Tioli Access Manager documentation describes this in detail. The pdosd daemon replicates the master Tioli Access Manager policy database and makes authorization decisions based on the information stored in this local replica. The first step in making an authorization decision is, therefore, obtaining a replica of the policy. The policy database is first replicated when Tioli Access Manager for Operating Systems is initially configured. The master policy database is maintained by the Tioli Access Manager policy serer. If the Tioli Access Manager policy serer is managing multiple secure domains, only the policy database associated for the local secure domain gets replicated. Updates to policy are distributed to replicas by the following methods: Actie notification When updates are made to the master policy database, the Tioli Access Manager policy serer informs replica serers that hae registered for notification that an update has occurred. The replica serers then download the updated database. Polling Replica serers periodically poll the Tioli Access Manager policy serer to see if any updates to the master policy database hae been made. If so, they then download the updated database. Tioli Access Manager for Operating Systems can use either or both of these methods. The configuration attributes, refresh-interal and ssl-listening-port, listed in Table 30 control whether the pdosd daemon listens actiely for policy update notifications or whether it polls the Tioli Access Manager policy serer at regular interals. The configuration attribute, ssl-local-domain, specifies the name of the local secure domain. This is the Tioli Access Manager secure domain that the pdosd daemon is configured to use. The attributes reside in the /opt/pdos/etc/pdosd.conf configuration file. Table 30. Authorization Configuration Attributes Stanza Attribute Description [policy] refresh-interal The interal in minutes that the Tioli Access Manager policy serer is polled for updates. A alue of zero indicates that polling should not occur. [ssl] ssl-listening-port The TCP/IP port assigned to the pdosd daemon to listen for policy update notifications from the Tioli Access Manager policy serer. A alue of zero indicates that policy updates should not be listened for. ssl-local-domain The name of the local secure domain. This is Tioli Access Manager secure domain that the pdosd daemon is configured to use. If the Tioli Access Manager policy serer is managing multiple secure domains, only the policy database associated with this domain gets replicated. When the Tioli Access Manager kernel extension intercepts a system operation that requires an authorization decision, it requests the decision from the pdosd daemon. The information that is proided by the kernel about the operation being performed is used to make the authorization decision. This information consists of: Chapter 3. Runtime 73

90 The numeric accessor identity of the user attempting the operation. This can be different from the UID of the process performing the operation because a process in which a surrogate operation has been performed will be running as the surrogate user identity. The accessor identity from a Tioli Access Manager for Operating Systems point of iew is still the original identity of the process. The accessor identity is typically established at login time and is the ID corresponding to the login. The resource that the operation is being applied to. The attempted operation. The time that the operation is occurring. The program being used to perform the operation. This information is compared by the pdosd daemon to the policy stored in the local replica of the policy database. Tioli Access Manager for Operating Systems decides whether or not the operation should be permitted based on the comparison. Only policy contained under the policy branch that the machine subscribes to is used in the comparison. The policy-branch is specified during initial configuration of Tioli Access Manager for Operating Systems. The configuration attribute listed in Table 31 specifies the policy-branch name and is found in the /opt/pdos/etc/osseal.conf file. During this process an operational error might occur if there is a hardware failure on the machine or if the system has insufficient irtual memory aailable. Tioli Access Manager for Operating Systems is structured to minimize the possibility of such eents impacting the authorization process. If the pdosd daemon is unable to make a decision based on the authorization policy, it applies a default decision based on whether the user is an administratie user or not. For an administratie user the default decision under error conditions is to grant access. Non-administratie users are denied access under error conditions. Table 31. Authorization Policy-branch Configuration Attribute Stanza Attribute Description [policy] branch Name of the policy branch to which this machine subscribes. TCB monitoring The resources that are included in the Trusted Computing Base are discussed in Trusted Computing Base resources on page 30. They include the following: Secure-Files Secure-Programs Login-Programs Impersonator-Programs Immune-Programs Immune-Surrogate-Programs In addition, programs listed in Access-Restrictions attribute entries with permit rules are also included in the TCB, because it must be erified that the program used to access the resource has not been corrupted. Note that programs listed in Access-Restrictions attribute entries with deny rules are not included in the TCB (unless the program is also in a permit rule or is a resource that is in the TCB, such as Secure-Programs). The following attributes make up a file s signature: 74 IBM Tioli Access Manager for Operating Systems: Administration Guide

91 File size File creation time File modify time File permissions File ownership File type (such as regular file, directory, or soft-link) Content checksum (for regular files) The interal oer which the pdosd daemon checks all the Trusted Computing Base files is configurable. The checking of the files is eenly distributed throughout this interal. If the Trusted Computing Base contains a large number of files, this interal might be too short to check eery file before the interal expires. If this situation occurs, the pdosd daemon generates warnings in its log file, /ar/pdos/log/msg pdosd.log. The pdosd daemon makes an explicit check of an executable file s signature when making an authorization decision initiated by the attempted execution of a program defined in the Trusted Computing Base. By default, this includes checking the CRC of the executable file. This behaior can be changed by using the -tcb_nocrc_on_exec configuration option. Seeral configuration attributes are aailable to control the amount of processing resource that the pdosd daemon should deote to Trusted Computing Base file monitoring. Table 32 on page 76 describes the attributes specified in the /opt/pdos/etc/pdosd.conf configuration file. Chapter 3. Runtime 75

92 Table 32. pdosd TCB File Monitoring Resource Configuration Attributes Stanza Attribute Description [tcb] monitor-threads interal Controls the number of threads engaged in Trusted Computing Base monitoring. The TCB monitoring load is eenly distributed among the threads. It is useful to increase this alue only on multi-processor systems. You do not need more monitor threads than CPUs. The interal in minutes oer which the entire TCB is scanned for changes. Increasing this interal reduces the load of the TCB monitoring system, but increases the time in which you can expect a change to be detected. max-checksum-file-size Controls the number of bytes that are considered significant in the calculation of a file s checksum. This proides a degree of checksum monitoring of ery large files without committing extensie computing resources. The bytes used in calculation of the checksum are chosen from locations distributed throughout the file instead of just at the beginning or end to maximize the probability of detecting a change. The most expensie operation performed in TCB monitoring is checksum calculation. ignore-ctime tcb_nocrc_on_exec Causes ctime to be ignored when performing TCB signature comparisons. When this option is enabled, a change in ctime does not cause the TCB resource to become untrusted. Causes the CRC data checksum that normally occurs as part of the authorization check associated with running an executable file that is registered in the TCB to be skipped. Enable this option if it is important to aoid performing the CRC check on large binary files. The trust states and signatures of TCB files are maintained on a per-machine basis in the object signature database and are not distributed back to the central Tioli Access Manager policy serer. This practice recognizes that the same file might hae different signatures on each machine and might be trusted or untrusted independently on each machine. When a file becomes untrusted, it remains untrusted until the pdosobjsig command is used to retrust it. You can also use the pdosobjsig command to generate lists of trusted or untrusted files and for other tasks related to maintaining and examining the state of the Trusted Computing Base object signature database. The pdosd log configuration The pdosd daemon maintains a log file called /ar/pdos/log/msg pdosd.log that records significant eents and error conditions associated with the daemon itself. Entries in this file are written in text format and consist of: A UTC (Uniersal Time Coordinated) timestamp Information identifying the component recording the message The message classification The message text 76 IBM Tioli Access Manager for Operating Systems: Administration Guide

93 Table 33 lists the attributes that control this log file. Table 33. pdosd Log Configuration Attributes Stanza Attribute Description [pdosd] log-entries logs The number of pdosd log entries to write before archiing the pdosd log file. The default alue of zero means that the number of entries to write is unlimited and the pdosd log file will not be archied. If log-entries is non-zero and logs is non-zero, the pdosd log file will be archied when the number of entries in it reaches the number of entries specified by log-entries or when the pdosd daemon is restarted. If log-entries is non-zero and logs is zero, the pdosd log file will be recycled when the number of entries in it reaches the number specified by log-entries or when the pdosd daemon is restarted. The number of pdosd archie log files to use before recycling the pdosd archie log files. Setting the number of pdosd archie log files to a non-zero alue has an effect only if the log-entries is non-zero. The pdosd log file will be archied when the number of entries in it has reached the number of entries specified by log-entries or when the pdosd daemon is restarted. The default alue of zero means neer archie the pdosd log file The pdosauditd audit daemon The pdosauditd audit daemon manages the Tioli Access Manager for Operating Systems audit log. The audit daemon receies binary audit records from the daemons, kernel extension, and the pdosobjsig command and stores them in memory and writes them to the audit log on a regular basis. The actie audit log is /ar/pdos/audit/audit.log. The pdostecd and pdoslrd daemons use the audit.log file as input. If the file is remoed, the daemons shut down and must be manually restarted after the audit.log file is made aailable again. The pdosauditd daemon must be shut down and then restarted in order to make the audit.log file aailable. Components generate audit records based on the audit-leel settings. For authorization decisions, the global audit leel, global warning leel, resource audit leel, resource warning leel, and per-user audit leel are all considered. In the case of a non-authorization decision, only the global audit leel is used. The global audit leel is set in the /opt/pdos/etc/osseal.conf configuration file. The format of the global audit-leel attribute in this file is shown in Table 34 on page 78. This configuration file is read by the daemons when they start. The pdosctl command can be used to change the global audit leel during system operation. Chapter 3. Runtime 77

94 Table 34. Global Audit-Leel Configuration Attribute Stanza Attribute Description [audit] leel The global audit leel in effect when the daemons are started. permit_actions deny_actions The global audit permit_actions in effect when the daemons are started. The global audit deny_actions in effect when the daemons are started. The pdosauditd daemon maintains a separate log file called /ar/pdos/log/msg pdosauditd.log that records significant eents and error conditions associated with the daemon itself. Entries in this file are written in text format and consist of: A UTC (Uniersal Time Coordinated) timestamp Information identifying the component recording the message The message classification The message text The pdosauditd configuration The configuration of the pdosauditd daemon is controlled by setting attributes in the /opt/pdos/etc/pdosauditd.conf file. Two attributes in this file control how the audit log is managed. The audit-logflush attribute specifies the frequency, in seconds, at which the pdosauditd daemon should flush audit records from memory to the audit log. By default, the log is flushed eery 5 seconds. The audit-logsize attribute specifies the maximum size, in bytes, that the audit log can reach before the audit log is renamed and a new audit log is started. A alue of zero indicates there is no maximum size for the audit log. The default size is bytes. When the audit log reaches the maximum size specified, the current audit log file in the /ar/pdos/audit directory is renamed using the current timestamp from audit.log to audit.log.yyyy-mm-dd-hh-mm-ss. Logging then continues in a new audit.log file in the same directory. Two other attributes in the configuration file control how the pdosauditd log is managed. The log-entries attribute specifies the maximum number of entries that can be written to the log before the log is renamed and a new one started. The default alue is zero, which indicates that the log should neer be rolled oer. The logs attribute specifies the maximum number of indiidual log files that can be written before the oldest one is reused. If the log-entries attribute is zero, this alue is ignored. Table 35 on page 79 describes all of the pdosauditd configuration file attributes for managing the audit.log file and the msg pdosauditd.log file. These settings also can be changed with the pdoscfg command described in pdoscfg on page IBM Tioli Access Manager for Operating Systems: Administration Guide

95 Table 35. pdosauditd Configuration Attributes Stanza Attribute Description [pdosauditd] audit-logflush audit-logsize log-entries logs Interal in seconds that the pdosauditd daemon flushes the audit records to the audit log. Maximum size in bytes to which the audit log can grow before pdosauditd rolls oer to use a new log file. The number of pdosauditd log entries to write before archiing the pdosauditd log file. The default alue of zero means that the number of entries to write is unlimited and the pdosauditd log file will not be archied. If log-entries is non-zero and logs is non-zero, the pdosauditd log file will be archied when the number of entries in it reaches the number of entries specified by log-entries or when the pdosauditd daemon is restarted. If log-entries is non-zero and logs is zero, the pdosauditd log file will be recycled when the number of entries in it reaches the number specified by log-entries or when the pdosauditd daemon is restarted.. The number of pdosauditd archie log files to use before recycling the pdosauditd archie log files. Setting the number of pdosauditd archie log files to a nonzero alue has an effect only if the log-entries is non-zero. The pdosauditd log file will be archied when the number of entries in it has reached the number of entries specified by log-entries or when the pdosauditd daemon is restarted. The default alue of zero means neer archie the pdosauditd log file. For information about enabling auditing, see Using auditing to erify policy on page 124. See Viewing audit logs on page 204 for information on iewing audit logs. The pdoswdd watchdog daemon The pdoswdd watchdog daemon monitors the aailability of the pdosd, pdosauditd, pdoslpmd, and pdoslrd daemons. These daemons monitor each other in the same manner; this is the watchdog daemon s only function. This self-monitoring function, as implemented by each of the daemons, is the watchdog system. The watchdog system ensures the high aailability of Tioli Access Manager for Operating Systems serices on a machine. Note: The pdostecd daemon, described in The pdostecd Tioli Enterprise Console daemon on page 81 is not monitored by the other daemons. When deployed, Tioli Access Manager for Operating Systems constitutes a core component of the system that it is protecting. Ensuring that it remains aailable is ital to maintaining the integrity of the system and helps protect against attacks that might cause the daemons to terminate abnormally. The pdoswdd daemon maintains a log file called /ar/pdos/log/msg pdoswdd.log that records significant eents and error conditions associated with the daemon itself. Entries in this file are written in text format and consist of: A UTC (Uniersal Time Coordinated) timestamp Information identifying the component recording the message The message classification Chapter 3. Runtime 79

96 The message text The pdoswdd configuration Configuration of the pdoswdd daemon is done using the pdoswdd configuration file, /opt/pdos/etc/pdoswdd.conf. The two attributes in the configuration file control how the pdoswdd log is managed: The log-entries attribute specifies the maximum number of entries that can be written to the log before the log is renamed and a new one started. The default alue is zero, which indicates that the log should neer be rolled oer. The logs attribute specifies the maximum number of indiidual log files that can be written before the oldest one is reused. If the log-entries attribute is zero, this alue is ignored. Table 36 describes the pdoswdd configuration file attributes for managing the msg pdoswdd.logfile. Table 36. pdoswdd Configuration Attributes Stanza Attribute Description [pdoswdd] log-entries logs The number of pdoswdd log entries to write before archiing the pdoswdd log file. The default alue of zero means that the number of entries to write is unlimited and the pdoswdd log file will not be archied. If log_entries is non-zero and logs is non-zero, the pdoswdd log file will be archied when the number of entries in it reaches the number of entries specified by log_entries or when the pdoswdd daemon is restarted. If log_entries is non-zero and logs is zero, the pdoswdd log file will be recycled when the number of entries in it reaches the number specified by log_entries or when the pdoswdd daemon is restarted. The number of pdoswdd archie log files to use before recycling the pdoswdd archie log files. Setting the number of pdoswdd archie log files to a nonzero alue has an effect only if the log_entries is nonzero. The pdoswdd log file will be archied when the number of entries in it has reached the number of entries specified by log_entries or when the pdoswdd daemon is restarted. The default alue of zero means neer archie the pdoswdd log file. If one of the daemons terminates abnormally, the watchdog system detects this and generates a log message in the error log of the daemon that detected the abnormal termination. Watchdog log messages can, therefore, appear in any daemon log file: pdosd /ar/pdos/log/msg pdosd.log pdosauditd /ar/pdos/log/msg pdosauditd.log pdoswdd /ar/pdos/log/msg pdoswdd.log 80 IBM Tioli Access Manager for Operating Systems: Administration Guide

97 pdoslpmd /ar/pdos/log/msg pdoslpmd.log pdoslrd /ar/pdos/log/msg pdoslrd.log If administratie audit eents are enabled, an audit eent also is written to the audit log to record the abnormal termination. The pdostecd Tioli Enterprise Console daemon The pdostecd daemon makes a subset of the audit eents produced by Tioli Access Manager for Operating Systems aailable to the Tioli Enterprise Console. The daemon reads the actie log file, /ar/pdos/audit/audit.log, and records releant audit eents to a file called /ar/pdos/tec/tec.log, which the Tioli Enterprise Console logfile adapter can monitor. A description of the eents made aailable can be found in Appendix C, Tioli Enterprise Console and Tioli Risk Manager eents, on page 295. If the pdostecd daemon cannot access the /ar/pdos/audit/audit.log file, the daemon shuts down. The daemon must be manually restarted after the audit.log file becomes aailable again. The tec.log file grows unbounded and must be cleared periodically to keep the /ar filesystem from becoming full. See Periodic log maintenance on page 82 for details. The pdostecd daemon maintains a log file called /ar/pdos/pdostecd/msg pdostecd.log that records significant eents and error conditions associated with the daemon itself. Entries in this file are written in text format and consist of: A UTC (Uniersal Time Coordinated) timestamp Information identifying the component recording the message The message classification The message text The pdostecd configuration Configuration of the pdostecd daemon is done using the pdostecd configuration file, /opt/pdos/etc/pdostecd.conf. The two attributes in the configuration file control how the pdostecd log is managed: The log-entries attribute specifies the maximum number of entries that can be written to the log before the log is renamed and a new one started. The default alue is zero, which indicates that the log should neer be rolled oer. The logs attribute specifies the maximum number of indiidual log files that can be written before the oldest one is reused. If the log-entries attribute is zero, this alue is ignored. Table 37 on page 82 describes the pdostecd configuration file attributes for managing the /ar/pdos/pdostecd/msg pdostecd.log file. Chapter 3. Runtime 81

98 Table 37. pdostecd Configuration Attributes Stanza Attribute Description [pdostecd] log-entries logs The number of entries that can be written to the pdostecd daemon log file before rolling oer to a new file. The default alue of zero indicates that the log file should neer be rolled oer. The number of log files to be written before recycling the first one. A alue of zero indicates that log files should neer be recycled. If the log-entries attribute is zero, this alue is ignored. Periodic log maintenance The /ar/pdos/tec/tec.log grows unbounded. This file must be cleared periodically to preent the /ar filesystem from running out of space. This can be accomplished by the Tioli Scheduler, or with a script using the UNIX cron utility. The basic operation of the script is as follows. 1. Stop the pdostecd daemon. This stops new records from being written to the log file. /opt/pdos/bin/rc.pdostecd stop 2. Sleep for a sufficient amount of time to allow the Tioli Enterprise Console UNIX logfile adapter to complete the processing of the existing records in the tec.log file. For instance, to sleep for 5 minutes: sleep Restart the pdostecd daemon. The daemon deletes the existing tec.log file and creates a new one. /opt/pdos/bin/rc.pdostecd start This operation should be done during periods of minimal actiity in the system. The pdostecd daemon attempts to resume processing of the audit log file at the place where it stopped. If there was a lot of audit actiity while the daemon was inactie, it is possible that the audit log file has wrapped. If the pdostecd daemon is unable to locate its resumption point, processing resumes at the end of the current audit log file. The pdoslpmd login policy and password management daemon The pdoslpmd daemon proides support for Tioli Access Manager for Operating Systems login actiity policy and password management enforcement. Processes that perform logins and password changes communicate with pdoslpmd to determine whether the operation is allowed under current Tioli Access Manager for Operating Systems policy. Login actiity and password management policy enforcement is enabled by default when Tioli Access Manager for Operating Systems is configured on the system. If login policy is not enabled on the system, the pdoslpmd daemon will not be running. If login policy is enabled after the initial Tioli Access Manager for Operating Systems configuration and start, then the pdoslpmd daemon will be started the next time that Tioli Access Manager for Operating Systems is started. Table 38 on page 83 lists the attribute specified in the /opt/pdos/etc/pdosd.conf configuration file that controls whether or not enforcement is enabled. 82 IBM Tioli Access Manager for Operating Systems: Administration Guide

99 Table 38. pdoslpmd Configuration Attribute Stanza Attribute Description [pdoscfg] login-policy on off Controls whether or not login actiity and password management policy enforcement is enabled. The pdoslpmd daemon relies on the pdosd daemon for operation. If pdoslpmd is running, but pdosd is not, then no enforcement of login or password management policy will occur. The pdoslpmd configuration There is no true configuration file for the pdoslpmd daemon. The /opt/pdos/etc/lpm.conf file is a local representation of the login actiity and password management policy for the Tioli Access Manager for Operating Systems host. It is maintained and updated by the Tioli Access Manager for Operating Systems runtime to keep the policy up to date with the policy specified in the name space. This file should not be updated by hand as such updates will be lost when new policy is processed by the Tioli Access Manager for Operating Systems runtime. The pdoslrd log router daemon The pdoslrd log router daemon reads a Tioli Access Manager for Operating Systems audit record from an input channel, formats the record, and then queues the record for the output channels to process. Each output channel dequeues a formatted audit record, applies a filter to it (if one has been specified for that channel), and, if the record is not filtered out, formats the record into the proper output format, and sends it to its destination. The pdoslrd daemon uses the audit.log file as input. If the file is remoed, the daemon shuts down and must be manually restarted after the audit.log file is made aailable. The pdosauditd daemon must be shut down and then restarted in order to make the audit.log aailable. The pdoslrd configuration There are two aspects to pdoslrd configuration: the initial configuration of the daemon, following installation, and the specification of the control file, which contains the parameters that are necessary to run the audit log application. Initial configuration is described here; specification of the control file is described in Chapter 4, The log router daemon, on page 97. Chapter 3. Runtime 83

100 Table 39 describes the pdoslrd configuration file attributes. Table 39. pdoslrd Configuration Attributes Stanza Attribute Description [pdoslrd] state log-entries logs lrd-local-domain lrd-admin-name The alue can be on or off. If pdoslrd has been configured, the state is on. Otherwise, the state is off. The number of pdoslrd log entries to write before archiing the pdoslrd log file. The default alue of zero means that the number of entries to write is unlimited and the pdoslrd log file will not be archied. If log_entries is non-zero, and logs is non-zero, the pdoslrd log file will be archied when the number of entries in it reaches the number of entries specified by log_entries or when the pdoslrddaemon is restarted. If log_entries is zero, the pdoslrd log file will recycled when the number of entries in it reaches the number specified by log_entries or when the pdoslrd daemon is restarted. The number of pdoslrd archie log files to use before recycling the pdoslrd archie log files. Setting the number of pdoslrd archie log files to a non-zero alue has an effect only if the log_entries is non-zero. The pdoslrd log file will be archied when the number of entries in it has reached the number of entries specified by log_entries or when the pdoslrd daemon is restarted. The default alue of zero means neer archie the pdoslrd log file. If pdoslrd has been configured to hae a local domain that is different from the one Tioli Access Manager for Operating Systems is configured to, it will appear here. The admin name used to configure pdoslrd. This name might be different from the Tioli Access Manager serer admin name if pdoslrd has been configured with a local domain that is different from the one Tioli Access Manager for Operating Systems is configured to. Users and groups Tioli Access Manager for Operating Systems uses arious Tioli Access Manager and UNIX users and groups. The necessary Tioli Access Manager users and groups are created during the initial configuration of Tioli Access Manager for Operating Systems. The UNIX users and groups are created on each Tioli Access Manager for Operating Systems system during installation. The role of each of these users and groups is discussed in this section. 84 IBM Tioli Access Manager for Operating Systems: Administration Guide

101 osseal-admin group The osseal-admin group is a Tioli Access Manager group that identifies users that are administratie users, or administrators. The corresponding UNIX group is called osseal. Administrators are treated slightly differently from general users, according to the following rules. Credentials of administrators are neer flushed from the disk cache. The credentials of a general user are flushed from the disk cache after the credential hold time expires for those credentials. Credentials of administrators are maintained on a system een if an administrator has neer logged on to the system. It is important to allow administrators to access a system they hae neer logged in to before, een if that system is isolated from the Tioli Access Manager user registry. General users do not hae a credential cached on a system until they hae logged in to it for the first time. The default decision made by the pdosd daemon when making a decision under error conditions is to grant access for administrators. For general users the default decision is to deny. The pdosd authorization daemon on page 68 has more information about such error conditions. When Tioli Access Manager for Operating Systems is configured for the first time, the membership of the osseal-admin group consists of two users, root and osseal. Do not remoe the osseal user ID from this group. osseal group The osseal group is a UNIX group that identifies users that are administratie users, or administrators on a particular system. This group corresponds to the osseal-admin group in Tioli Access Manager. This group is used to permit access using the arious setgid commands proided by Tioli Access Manager for Operating Systems to resources protected by UNIX security under the /ar/pdos directory. This group is the primary group of the osseal UNIX user ID. Do not remoe the osseal user ID from this group. Users who are members of both the osseal-admin and osseal groups are called Tioli Access Manager for Operating Systems runtime administrators and are authorized to perform the tasks associated with managing the Tioli Access Manager for Operating Systems runtime enironment. osseal user The osseal user is represented in both Tioli Access Manager and UNIX. Tioli Access Manager for Operating Systems treats this user in a special way on the UNIX system. The osseal user is an identity that the Tioli Access Manager for Operating Systems daemons and commands adopt when they are running. root user Configuring Tioli Access Manager for Operating Systems initially creates a Tioli Access Manager user ID of root. This user corresponds to the root UNIX user to ensure that root can neer be treated as an unauthenticated user. The root user is initially made a member of the osseal-admin group. The root user s membership in the osseal-admin group ensures that the root user s credentials are always aailable on all Tioli Access Manager for Operating Systems systems. The root user represents the UNIX root user across all Tioli Access Manager for Operating Systems systems sharing the same Tioli Access Manager user registry. Chapter 3. Runtime 85

102 osseal-auditors group The osseal-auditors group is a Tioli Access Manager group that identifies users that are auditors. The corresponding UNIX group is called ossaudit. When Tioli Access Manager for Operating Systems is configured for the first time, the membership of the osseal-auditors group consists of two users, root and ossaudit. ossaudit group The ossaudit group is a UNIX group that identifies users that are auditors. This group corresponds to the osseal-auditors group in Tioli Access Manager. The osseal user is a member of this group. Users who are members of both the osseal-auditors and ossaudit groups are called Tioli Access Manager for Operating Systems auditors and are authorized to perform the tasks associated with accessing the Tioli Access Manager for Operating Systems audit trail. Do not remoe the osseal user ID from this group. osseal-unauth user The osseal-unauth user has only a Tioli Access Manager representation. It has no UNIX equialent. It controls time-of-day login restrictions for unauthenticated, from a Tioli Access Manager point of iew, users independently from authenticated users. This is similar to the role of the unauthenticated entry in an ACL entry. pdosd-hostname user The Tioli Access Manager policy serer does not allow eery user to replicate the policy database. A Tioli Access Manager user is created during configuration for each instance of the pdosd daemon that runs in the secure domain managed by the Tioli Access Manager policy serer. Because one of these users is created for each Tioli Access Manager for Operating Systems system, the fully qualified DNS host name for the machine is included in the name, for example, pdosd-hostname user. When the DNS name is not aailable, the host s name is used instead. The pdosd daemon authenticates to the Tioli Access Manager policy serer as this user in order to receie policy updates. Do not modify this user and its group membership. critical cred group The critical cred group defines the Tioli Access Manager group that identifies users that should be considered critical to system operation. It is configurable with the critical_cred_group option to the pdoscfg command. Critical users are treated slightly differently from general users, according to the following rules: Credentials of critical users are neer flushed from the disk cache. Credentials of critical users are maintained on a system een for critical users that hae neer logged on. This is important to allow critical users to access a system they hae neer logged on to een if the system is isolated from the Tioli Access Manager user registry. The critical cred group is optional and does not need to be configured. It does not need to hae a corresponding local UNIX group. The members of the group must hae corresponding local UNIX IDs or they will be ignored. 86 IBM Tioli Access Manager for Operating Systems: Administration Guide

103 Files and directories Tioli Access Manager for Operating Systems installs itself into common locations on all platforms. This is necessary because arious components hae important implications to the security of the system and access is controlled to these components using Tioli Access Manager for Operating Systems policy. A simpler policy results if the location of common resources is consistent across systems. This section summarizes the role of the arious files and directories used by Tioli Access Manager for Operating Systems. /opt/pdos/bin Contains all of the binary executable images that comprise the user-leel runtime. /opt/pdos/etc Contains configuration files for the arious components that use configuration files. This directory also contains other administratie information, such as descriptions of the initial policy established during configuration, the files and directories that are backed up and restored by the pdosbkup and pdosrstr commands, and template configuration files that proide basic descriptions of the arious configuration attributes. The particular components include: /opt/pdos/etc/trace This directory contains the default routing files for Tioli Access Manager for Operating Systems daemons and commands. osseal.conf A general configuration file containing configuration common to all components. pdosd.conf The pdosd daemon s configuration file. pdosauditd.conf The pdosauditd daemon s configuration file. pdoslrd.conf The pdoslrd daemon s configuration file. pdoslrd.xml The pdoslrd daemon s control file. pdoswdd.conf The pdoswdd daemon s configuration file. pdostecd.conf The pdostecd daemon s configuration file. pdossudo.conf The pdossudo configuration file. lpm.conf The login actiity and password management policy enforcement configuration file. /opt/pdos/kernel Contains binaries and files related to Tioli Access Manager for Operating Systems kernel functionality. Chapter 3. Runtime 87

104 /opt/pdos/lib Contains the shared libraries that contain executable code shared by the arious commands. /opt/pdos/nls Contains language-specific files. /opt/pdos/sbin Contains binaries and scripts related to problem determination. /ar/pdos/audit Contains the Tioli Access Manager for Operating Systems audit file, /ar/pdos/audit/audit.log. /ar/pdos/azn Contains the local replica of the Tioli Policy Director policy database in authzn_replica.db. /ar/pdos/certs Contains files that contain the certificates that the pdosd and pdoslrd daemons use when mutually authenticating with both the Tioli Access Manager policy serer and the LDAP user registry serer. /ar/pdos/cred Contains the cached Tioli Access Manager credentials. /ar/pdos/ffdc This directory is used to store data captured by the first failure data capture tools. /ar/pdos/hla Contains the host look-aside database that is used to cache IP-address-to-hostname mappings when this feature is enabled. /ar/pdos/log Contains the log files for all of the daemons (except the pdostecd daemon) and the configure, unconfigure, backup, and restore commands. /ar/pdos/login Contains temporary files associated with the login actiity policy. /ar/pdos/lpm Contains the local machine information needed to enforce login account actiity and password management policy. /ar/pdos/pdosauditd This directory is used as the current working directory for the pdosauditd daemon while it is running. If an error resulting in a core file occurs, this directory is where the core file will be located. /ar/pdos/pdosbkup This directory is used as the current working directory for the pdosbkup and pdosrstr commands while they are running. The backup file created by the pdosbkup command is written to this directory by default. If an error resulting in a core file occurs during the execution of either command, this directory is where the core file will be located. /ar/pdos/pdoscfg This directory is used as the current working directory for the pdoscfg and pdosucfg commands while they are running. If an error resulting in a core file occurs, this directory is where the core file will be located. 88 IBM Tioli Access Manager for Operating Systems: Administration Guide

105 /ar/pdos/pdosd This directory is used as the current working directory for the pdosd daemon while it is running. If an error resulting in a core file occurs, this directory is where the core file will be located. /ar/pdos/pdoslrd This directory is used as the current working directory for the pdoslrd daemon while it is running. It contains the input channel s last input processed (.lrp) file and the output file cache. /ar/pdos/pdosteccfg This directory is used as the current working directory for the pdosteccfg and pdostecufg commands while they are running. If an error resulting in a core file occurs, this directory is where the core file will be located. /ar/pdos/pdostecd This directory is used as the current working directory for the pdostecd daemon while it is running. If an error resulting in a core file occurs, this directory is where the core file will be located. This is also the location of the error log for the pdostecd daemon. /ar/pdos/pdoswdd This directory is used as the current working directory for the pdoswdd daemon while it is running. If an error resulting in a core file occurs, this directory is where the core file will be located. /ar/pdos/tcb Contains the information used to detect changes to the files comprising the Trusted Computing Base. /ar/pdos/tec Contains the file with audit eents that is monitored by the Tioli Enterprise Console logfile adapter. /ar/pdos/tracelogs Contains the default trace log files for Tioli Access Manager for Operating Systems daemons and commands. /ar/pdos/uid Contains the cache of UIDs and GIDs to user and group names when this feature is enabled. No management of this cached information is required. /ar/pdos/umsg Contains files used for inter-process communication and synchronization between components of Tioli Access Manager for Operating Systems. /ar/pdos/watch Contains files used by the watchdog system to detect abnormal termination of the pdosd, pdosauditd, pdoswdd, pdoslrd, or pdoslpmd daemons. Initial policy The following components of the policy are established when Tioli Access Manager for Operating Systems is initially configured: once-only This policy is shared across all policy branches. It comprises the actions used to represent Tioli Access Manager for Operating Systems operations, ACLs used to protect resources, the users and groups discussed preiously, and the /OSSEAL object space under which all protected objects reside. Chapter 3. Runtime 89

106 per-machine This policy is established for each machine. It comprises the actions used to track branch membership. per-policy This policy is established for each policy branch that you use. It describes the contents of the Trusted Computing Base and attaches the ACLs and POPs that Tioli Access Manager for Operating Systems uses to protect itself from being compromised. The default policy established by Tioli Access Manager for Operating Systems ensures that the system functions properly and maintains a secure enironment. The existing default policy should not be modified. The remainder of this section describes the ACLs established during policy creation and the resources that they protect. The default policy is sufficient to protect Tioli Access Manager for Operating Systems without adding any additional authorization policy to other resources on a system, except for system programs defined as initial members of the Trusted Computing Base. See Trusted Computing Base resources on page 30 for more information about the initial population of the Trusted Computing Base. osseal-audit This ACL controls access to the /ar/pdos/audit directory, where the Tioli Access Manager for Operating Systems audit trail resides. It also controls access to /ar/pdos/pdoslrd, /ar/pdos/pdostecd, and /ar/pdos/tec. The ACL permits only members of the osseal-auditors group to access the directory or, by inheritance, its contents. osseal-audit-exec This ACL controls access to the pdosaudiew command, /opt/pdos/bin/pdosaudiew. Members of the osseal-auditors group are granted full access to this command. All other users are restricted from using this command. osseal-credentials This ACL controls access to the directories that make up the Tioli Access Manager for Operating Systems credential cache: /ar/pdos/cred and /ar/pdos/uuid. It grants all users the ability to refresh and destroy credentials, but only by using the pdosrefresh and pdosdestroy commands. Tioli Access Manager for Operating Systems ensures that users are allowed to refresh and destroy only their own credentials unless granted access by access controls to the credential cache directories. This ACL restricts the ability to refresh or destroy any user s credentials to members of the osseal-admin group. osseal-default This is a fully permissie ACL. It is applied at namespace root for Tioli Access Manager for Operating Systems: /OSSEAL. Its presence ensures that authorization decisions neer propagate all the way to the root of the Tioli Access Manager object name space. 90 IBM Tioli Access Manager for Operating Systems: Administration Guide

107 osseal-default-file This is a fully permissie ACL that is in place as a reminder that Tioli Access Manager for Operating Systems File resources iolate the Tioli Access Manager inheritance algorithm by not inheriting ACLs from those placed aboe File in the tree. osseal-default-login This ACL defines default Login resource policy. It permits eeryone to log in. osseal-default-net-incoming This ACL defines default NetIncoming resource policy. It permits incoming connections from any host to any serice to be accepted by any user. If limited network access inheritance is enabled (-net_acl_limited configuration option), the ACL at the NetIncoming resource will not actually be enforced and will sere as a reminder that an implicit ACL is assumed, like the osseal-default-file ACL. osseal-default-net-outgoing This ACL defines default NetOutgoing resource policy. It permits any user to make outgoing connections to any host to access any remote serice. If limited network access inheritance is enabled (-net_acl_limited configuration option), the ACL attached at the NetOutgoing resource will not actually be enforced and will sere as a reminder that an implicit permissie ACL is assumed, like the osseal-default-file ACL. osseal-default-sudo This ACL defines default Sudo resource policy. It permits any user to execute any Sudo command osseal-default-surrogate This ACL defines default Surrogate resource policy. It permits anybody to surrogate to any user or group. osseal-exec-open This ACL controls access to the /opt/pdos/lib and /opt/pdos/nls directories and the non-administratie commands in the /opt/pdos/bin directory: pdosdestroy, pdosrefresh, pdossudo, and pdoswhoami. This ACL permits any user access to the non-administratie commands and to the Tioli Access Manager for Operating Systems shared libraries used by these commands, along with the message catalogs. osseal-exec-root This ACL controls access to the /opt/pdos/bin/pdoslpmd, /opt/pdos/bin/pdostecd, /opt/pdos/bin/pdosshowmsg, and /opt/pdos/bin/rc.pdostecd commands. This ACL restricts the ability to execute these commands to root and members of the osseal-admin group. osseal-hla This ACL controls access the IP address to hostname cache maintained by Tioli Access Manager for Operating Systems in the /ar/pdos/hla directory. It permits administration of the cache by members of the osseal-admin group using the pdoshla command Chapter 3. Runtime 91

108 osseal-kazndr This ACL controls access to the Tioli Access Manager for Operating Systems deice /de/kazndr. It is necessary to allow PAM-enabled programs to read and write to the deice in order to communicate with the Tioli Access Manager for Operating Systems kernel module. Only members of the osseal-admin group are allowed to modify or remoe the deice. osseal-logs This ACL controls access to log files generated by the Tioli Access Manager for Operating Systems daemons and commands in the /ar/pdos/log, /ar/pdos/ffdc, and /ar/pdos/tracelogs directories. It restricts access to the directory to members of the osseal-admin group and prohibits Change Ownership (o), Change Permission (p), and Update Timestamp (U) actions, een to members of this group. osseal-open This ACL controls access to the /opt/pdos/etc/lpm.conf and /opt/pdos/etc/pdossudo.conf files. It permits any user to read the files, but not to modify them. Members of the osseal-admin group are granted full access to resources protected by this ACL. osseal-priileged-user This ACL controls the ability to surrogate to the osseal UNIX user. Access is restricted to members of the osseal-admin group although any user can also surrogate to osseal using the pdossudo command. This is necessary because the pdossudo command must perform a surrogate operation to the osseal user so that the correct authorization decision can be made when a user attempts to execute a Sudo command. Disabling the pdossudo command s ability to surrogate to the osseal user also disables the function of the Sudo command. osseal-restricted This ACL protects the more sensitie information associated with Tioli Access Manager for Operating Systems. It grants full access to members of the osseal-admin group and denies all access to non-members. It is attached to the /opt/pdos/etc, /opt/pdos/etc/trace, /ar/pdos/pdosbkup, /ar/pdos/pdoscfg, /ar/pdos/pdosteccfg, and /ar/pdos/certs directories. Note: The pdossudo.conf file in the /opt/pdos/etc directory has the osseal-open ACL directly attached and is, by default, less restricted. osseal-restricted-read This ery restrictie ACL controls the ability to start and stop the Tioli Access Manager for Operating Systems daemons and to execute the administratie commands. It only grants Change Directory (D), Read (r), List Directory (l), Kill (k), and Execute (x) permission to members of the osseal-admin group and denies non-members any access at all. It protects all the directories under both /ar/pdos and /opt/pdos that maintain runtime state that do not require administratie action. osseal-tcb This ACL controls access to the Trusted Computing Base object signature database maintained by Tioli Access Manager for Operating Systems in /ar/pdos/tcb. 92 IBM Tioli Access Manager for Operating Systems: Administration Guide

109 This ACL restricts access to this directory to members of the osseal-admin group. They can only access resources contained by this directory by using the pdosobjsig command. osseal-umsg This ACL restricts access to the /ar/pdos/umsg directory that is inoled with communication between the arious Tioli Access Manager for Operating Systems components. Access is allowed only when using a Tioli Access Manager for Operating Systems command that requires access to this directory. osseal-ar-lpm This ACL controls access to the /ar/pdos/lpm and /ar/pdos/login directories. It permits any user read and write access to the files underneath the /ar/pdos/lpm directory. This access is necessary to ensure that the Login Actiity Policy enforcement code can function properly. Members of the osseal-admin group and the root user are granted full access to resources protected by this ACL. Isolated operation During normal operation, Tioli Access Manager for Operating Systems relies on the network to communicate with the Tioli Access Manager policy serer, the Tioli Access Manager user registry (LDAP), and, in some cases, a non-local UNIX user registry such as NIS, and a non-local host name database such as a DNS serer. Tioli Access Manager for Operating Systems can continue to function in an enironment in which it becomes isolated from one or more of these serers, registries, or the network itself. Isolation means the loss of ability to communicate. This loss can occur for arious reasons: The network itself might be down in which case IBM Tioli Access Manager for Operating Systems is isolated from eerything The Tioli Access Manager policy serer might be down The Tioli Access Manager user registry (LDAP) might be down The NIS serer may be down The DNS serer might be down The following sections discuss isolation types and how each type affects Tioli Access Manager for Operating Systems. Isolation from the Tioli Access Manager policy serer If Tioli Access Manager for Operating Systems becomes isolated from the Tioli Access Manager policy serer, the pdosd daemon is unable to receie updates to the policy database. Any updates made to the policy on the master policy database will not be propagated to Tioli Access Manager for Operating Systems until communication between Tioli Access Manager for Operating Systems and the Tioli Access Manager policy serer is re-established. See Authorization decision process on page 73 for a description of the pdosd daemon s interaction with the Tioli Access Manager policy serer. During normal operation of the pdosd daemon, all policy decisions are made using the local replica of the policy database in combination with the Trusted Computing Base. During the time that the pdosd daemon is isolated from the Tioli Access Manager policy serer, all policy decisions will continue to be made by using the local replica of the policy database. When the pdosd daemon has re-established communication with the Tioli Access Manager policy serer, any pending updates to the policy database are receied through the specified means, actie notification or polling. Chapter 3. Runtime 93

110 Isolation from the Tioli Access Manager user registry If Tioli Access Manager for Operating Systems becomes isolated from the Tioli Access Manager user registry (LDAP), the PDOSD daemon is unable to obtain new Tioli Access Manager credentials. This means that the pdosd daemon is unable to obtain new credentials for users as they log into the system and it is unable to refresh cached credentials. See Credential acquisition on page 68 for a description of how credentials are managed by the pdosd daemon in normal operation. When the pdosd daemon detects that it has become isolated from the LDAP user registry, it does not remoe any credentials from the cache een if they are oerdue for a refresh or hae exhausted their hold interal. This lets any user who is currently logged in to the system to continue to function normally using the cached credential. Any user with a cached credential can log in to the system while the pdosd daemon is isolated from the LDAP user registry and will use their cached credential. If a user who does not hae a cached credential logs in while the pdosd daemon is isolated from the LDAP user registry, that user will run as an unauthenticated user. Administratie and critical system users always hae a cached credential. If either type of user logs in while the pdosd daemon is isolated from the LDAP user registry, that user always has a cached credential aailable. When the pdosd daemon is once again able to communicate with the LDAP user registry, it refreshes any credentials that should hae been refreshed during the time of isolation from the LDAP user registry. The Tioli Access Manager per-user time-of-day login restrictions are also stored in the LDAP user registry. The time-of-day login restrictions are retrieed by the pdosd daemon when a user logs in and are cached along with the credentials. When the pdosd daemon is isolated from the LDAP user registry it uses the cached time-of-day login restrictions. Isolation from non-local UNIX user registry Systems using a non-local UNIX user registry, such as NIS, might become isolated from that user registry. When this happens, users might not be able to log in to the system. Users who are logged in should be able to retriee new Tioli Access Manager credentials or use existing cached credentials. The user s natie numerical UNIX ID is conerted to the user s UNIX name using standard UNIX operating system functions that communicate with the non-local UNIX user NIS or NIS+ registry. The UNIX identity and its relationship to the Tioli Access Manager user identity on page 3 explains how Tioli Access Manager credentials are obtained. If the Tioli Access Manager for Operating Systems system becomes isolated from its user registry this conersion will not succeed. Tioli Access Manager for Operating Systems includes a UNIX uid/gid to username/groupname cache that can be enabled when Tioli Access Manager for Operating Systems is configured. When the UNIX uid/gid to username/groupname cache is enabled and the pdosd daemon becomes isolated from its UNIX user registry, the pdosd daemon uses this 94 IBM Tioli Access Manager for Operating Systems: Administration Guide

111 cache to map the UNIX ID to the UNIX name. After the UNIX name is known, the pdosd daemon can retriee the credential from the Tioli Access Manager user registry (LDAP) or the credential cache. This cache is only eer used as a backup and is only needed when users log in or perform Surrogate operations. By default, the UNIX uid/gid to UNIX username/groupname cache is not enabled because the remote UNIX registry serice is likely to proide its own mechanism for caching this information. If the remote UNIX registry serice you are using does not proide such a caching feature, you can enable the Tioli Access Manager for Operating Systems uid/gid cache by entering: pdoscfg -uid on See the IBM Tioli Access Manager for Operating Systems Installation Guide for details on configuring. Isolation from the hostname resolution serer Tioli Access Manager for Operating Systems can become isolated from a remote hostname resolution serer such as DNS or NIS. If this happens, IBM Tioli Access Manager for Operating Systems might be isolated from the Tioli Access Manager policy serer, the Tioli Access Manager user registry, and in some cases a non-local UNIX user registry. The sections aboe describe the behaior of Tioli Access Manager for Operating Systems in each of these cases. Isolation from the hostname resolution serer can cause additional problems. Tioli Access Manager for Operating Systems network policy may be specified by using either an IP address or a DNS hostname. The pdosd daemon must be able to conert the IP address to a DNS hostname when making policy decisions for network resources identified by hostname. Tioli Access Manager for Operating Systems includes an IP Address to Hostname Cache to allow the pdosd daemon to continue to perform this conersion een when isolated from a remote hostname resolution serer. By default, the IP Address to DNS Hostname Cache is enabled. Use the pdoshla command to manage the IP Address to DNS Hostname Cache. You can use this command to prepopulate entries in the cache. If your operating system proides a local IP Address to DNS Hostname Cache, you might want to disable this feature. Enter pdoscfg -dns off to disable this feature or set the dns attribute of the [cache] stanza in the /opt/pdos/etc/osseal.conf configuration file to off. See the IBM Tioli Access Manager for Operating Systems Installation Guide for details on configuring. The Tioli Access Manager for Operating Systems IP Address to Hostname Cache is always consulted first before querying a remote hostname resolution serice. This is done to ensure that the authorization of network accesses is performed efficiently. Because this cache is queried first, stale information might be used. Tioli Access Manager for Operating Systems caches IP address to hostname mapping for six hours after which the cache entry is refreshed on the next lookup. If you must erify that a host s IP address change is reflected immediately, use the pdoshla command to immediately remoe stale entries from the cache. Chapter 3. Runtime 95

112 96 IBM Tioli Access Manager for Operating Systems: Administration Guide

113 Chapter 4. The log router daemon This chapter contains information about how to modify the control file in order to run the pdoslrd daemon and how to specify and use the channel types. It also proides: record fields field alues output formats Log router control file A control file is used to specify the arious parameters necessary to run the pdoslrd daemon. The pathname of this file is /opt/pdos/etc/pdoslrd.xml. Use a text editor to modify this file. You can also use the pdoslradm command to iew and modify certain options of the Channel elements. The format of this control file must comply with the XML 1.0 specification. Note: The log router control file, pdoslrd.xml, is encoded in UTF-8. This means that all the characters in the file are interpreted as UTF-8. As a result, the file should only be edited using an editor that supports UTF-8. If your locale is en_us, any editor that supports ASCII will suffice. The following sections identify and define the arious control options supported by pdoslrd. The first section contains a sample control file. Log router control file example The following example shows a control file with an input channel and three output channels. All audit records are sent to the Tioli Access Manager authorization serer named gerrywaix. Only login denies are sent to the LRD_ Output channel. The file-admin channel is off. <?xml ersion="1.0" encoding="utf-8"?> <!DOCTYPE Serer SYSTEM "opt/pdos/etc/pdoslrd.dtd"> <Serer> <Router name="router 1" state="on" <Channel name="input" type="lrd_auditinput" path="ar/pdos/audit/audit.log" state="on"/> <Channel name="file-admin" type="lrd_fileoutput" path="ar/pdos/pdoslrd/audit.out" format="keyalue" state="off"/> <Channel name="mail-admin" type="lrd_ output" serer="d .de.tioli.com" port="25" address="admin@myhost.tioli.com" port="7136" filter="login-deny" state="on"/> <Channel name="netout-admin" type="lrd_netotput" serer="gerrywaix.de.tioli.com" port="7136" compress="yes" state="on" </Router> <Filters> <Filter name="login-deny"> <Conditional type="include"> <Field name="resource_type" alue="login"/> <Field name="iew" alue="d"/> </Conditional> Copyright IBM Corp. 2000,

114 </Filter> </Filters> </Serer> Log router control file elements The log router control file is comprised of the following elements: XML header Serer element Router element Channel element Filters element Filter element Conditional element Field element XML header The XML header is required by the XML specification and should comprise the first lines in the log router control file. These lines are as follows: <?xml ersion="1.0" encoding="utf-8"?> <!DOCTYPE Serer SYSTEM "opt/pdos/etc/pdoslrd.dtd"> Serer element The log router control file must contain exactly one Serer element. All other elements are contained within the Serer element. Usage <Serer> </Serer> Options completion_action Begin tag End tag An action to be taken when processing of an audit log archie file has completed. The default is none. Other possible alues are rename, which means the suffix.lrd will be added to the file name, and delete, which means that the file will be deleted. Router element The log router control file must contain at least one Router element. Each Router element must contain at least one input channel and one output channel definition. In this release, only one router element per control file is supported. Usage Usage <Router> </Router> Options name state Begin tag End tag The name of the router (a unique name). This is required. The state of the router (on or off). This is required. 98 IBM Tioli Access Manager for Operating Systems: Administration Guide

115 hi_ water batch_mode The maximum number of audit records that can be queued up for the output channels to process. When this point is reached for any output channel, the log router will stop reading records from the input channel until the output channel remoes at least one record from its queue. The default alue is 50. If the alue zero is specified, the output channel queues may grow unbounded, unless the pdoslrd process s irtual memory is exhausted. If batch_mode is enabled, the log router will wait for a signal from pdoslradm, then process all the unprocessed audit records currently in the audit log files. Any new audit records that are generated during processing will not be processed until the next time a signal is receied from pdoslradm. This option allows the user to control when the audit records are processed, so that processing can be done at a conenient time, such as a non-peak-load times. (the default alue is off.) For more information about this option, see the description of the -b option of the pdoslradm command in pdoslradm on page 249. Example <Serer> <Router name="router1" state="on" hi_water="500" <!-- Input channel definition --> <Channel name="audlog" type="lrd_auditinput" path="/ar/pdos/audit/audit.log" state="on" /> <!-- Output channel --> <Channel name="file" type="lrd_fileoutput" path="/home/sysadmin/audit.out" format="concise" state="on"/> </Router> </Serer> Channel element The Channel element is used to specify an input channel and one or more output channels used by a particular router to process records. The input channel reads data records from a particular source and prepares the record for processing by the output channels. The output channels format the data record for output and apply any filtering or formatting that has been defined. Only one filter element can be defined per output channel, but the filter element can hae multiple conditional elements, which allow for sophisticated filtering of the records. Channels are implemented as dynamically loaded libraries. The Channel element applies to a particular Router and can only be used between Router tags. Usage Usage <Channel.../> Channel element Options name type state The name of the channel (a unique name). This is required. The type of channel (such as LRD_FileOutput). This is required. The state of the channel (on or off). This is required. Chapter 4. The log router daemon 99

116 path filter error format max_files rolloer_size delimiter serer port rebind compress dn buffer flush_interal queue_size hi_water address The directory and name of the input or output file. The name of the filter to be used (output channels only). Only one filter can be defined per output channel. Error Retry Timeout. The number of seconds to wait before retrying on error. (output channels only). [default=2] The name of the format for this channel (LRD_FileOutput and LRD_ Output channels only). Value may be concise, keyalue, or erbose. [defaults: LRD_FileOutput=keyalue; LRD_ Output=erbose] Note: These three formats are the same as the pdosaudiew output formats. Maximum number of rolloer files. When this number is reached, the output file will grow without bound. A alue of zero means there is no maximum number of rolloer files. (LRD_FileOutput channels only). [default=0] Maximum size (in bytes) of an output file. When an output file reaches this size, a rolloer is performed. A alue of zero means that the file will grow indefinitely. (LRD_FileOutput channels only). [default=0] Field delimiter alue. This can be used to change the field delimiter alue for concise or keyalue format (for this channel only) from the default alue of comma. (LRD_FileOutput and LRD_ Output channels only). The host name to send the record to (only for LRD_ Output and LRD_NetOutput channels). The port number on the serer (only for LRD_ Output and LRD_NetOutput channels). [defaults: LRD_ Output=25; LRD_NetOutput=7136] Rebind Retry Timeout. The number of seconds to wait before rebinding to the serer after it has become unaailable (only for LRD_ Output and LRD_NetOutput channels). [defaults: LRD_ Output=60; LRD_NetOutput=300] Whether to compress records (yes or no) (LRD_NetOutput channels only). Records will be uncompressed on the serer machine. [default=no] Distinguished Name of remote serer (LRD_NetOutput channels only). The maximum sized message (in bytes) that will be constructed by combining audit records into a large buffer. Audit records are not split across buffers. (LRD_NetOutput channels only). [default=16384] The maximum number of seconds an audit record will reside in a buffer before being forwarded (LRD_NetOutput channels only). [0=no limit; default=1000] Maximum number of audit records that can be queued before blocking the requesting thread (LRD_NetOutput channels only). [0=no limit; default=1000] Processing the input queue is scheduled regularly at the flush interal. It is also triggered by the queue size reaching the high water mark (LRD_NetOutput channels only). [default=2/3 x queue size. If queue size equals zero, default =100] address (LRD_ Output channels only). 100 IBM Tioli Access Manager for Operating Systems: Administration Guide

117 Examples The following examples show an input channel and seeral output channels. <!-- This is an input channel that will read using the base file specified by the path --> <Channel name="log_input" type="lrd_auditinput" path="/ar/pdos/audit/audit.log" state="on" /> <!-- This is an output channel that will write data records to the directory and file specified by the path. The format is the concise output of the pdosaudiew command.--> <Channel name="fileout1" type="lrd_fileoutput" path="/ar/pdos/pdoslrd/audit.out" format="concise" state="on" /> <!-- This is an output channel that will write data records to . --> <Channel name="mail1" type=lrd_ output" serer="mailser.tioli.com" port="25" state="on"/> <!-- This is an output channel that will write data records to the serer specified by serer and port. The format is fixed for this destination and cannot be changed. --> <Channel name="netout-admin" type=lrd_netoutput" serer="toasty.ibm.com" port="7136" state="on" /> Filters element The log router control file can contain only one Filters element. All Filter elements are contained within the Filters element. It has no options. Usage Usage <Filters> </Filters> Options None Begin tag End tag Filter element The Filter element is used to specify the conditions under which a particular record will be included or excluded. A Filter element must contain at least one Conditional element. All Filter elements are contained within the Filters element. Only one Filter element can be defined per output channel. Usage Usage <Filter> </Filter> Options name Begin tag End tag A unique filter name. Examples <Filters> <!-- This is a filter with an include type Conditional element. The record will be included if the alue of the field "resource_type" is "Login" AND the alue of the field "iew" is "D" (for Deny) --> Chapter 4. The log router daemon 101

118 <Filter name="filter1"> <Conditional type="include"> <Field name="resource_type" alue="login" /> <Field name="iew" alue="d" /> </Conditional> </Filter> <!-- This is a filter with an exclude type Conditional element. The record will be excluded if the alue of "iew" is "Trace". --> <Filter name="filter2"> <Conditional type="exclude"> Field name="iew" alue="trace" /> </Conditional> </Filter> </Filters> Conditional element A Conditional element specifies one set of conditions under which a Filter element may be ealuated. A Filter element contains one or more Conditional elements. The first Conditional element that ealuates as true determines whether a record is included in the output. If a Conditional element of type include ealuates as true, the record is included in the output. If a Conditional element of type exclude ealuates as true, the record is excluded from the output. In order for a Conditional element to ealuate as true, all of its Field elements must match the record in question. That is, the field specified in the Field element must contain the same alue in the record as appears in the Field element. If none of the Conditional elements in a Filter element ealuate as true, then the disposition of the record is determined by the type of the last Conditional element contained within the Filter element. If the type is include, then the record is excluded. If the type is exclude, then the record is included. Usage Usage <Conditional> </Conditional> Options type Begin tag End tag include or exclude Examples <!-- include only records with resource_type=login AND iew=d OR records with outcome=f --> <Filter name="filter1> <Conditional type="include"> <Field name="resource_type" alue="login" /> <Field name= "iew" alue="d" /> </Conditional> <Conditional type="include"> <Field name="outcome" alue="f" /> </Conditional> </Filter> 102 IBM Tioli Access Manager for Operating Systems: Administration Guide

119 Field element The Field element is used to specify the fields to use when applying an output filter. The name of the field is one of the log router field names listed in the Field Table later in this document. The alue of a Field element is case-sensitie. This element can only be used between Conditional tags. Usage Usage <Field.../> Field element Options name alue name2 alue_list The name of the field. This is required. The alue of field name which constitutes a match. The name of a second field. If the contents of field name equals the contents of field name2, it is a match. The pathname of a file containing a list of alues (one per line). If the alue of the field specified by name is equal to any of the alues in the file, this is considered a match. A hashing scheme is used to determine if there is a match. Example <!-- Field element used inside a Conditional element. --> <!-- The alue of a Field element is case-sensitie.--> <!-- The record will be included if the alue of field "iew" is "D".--> <Conditional type="include"> <Field name="iew" alue="d"/> </Conditional> <!-- The record will be excluded if the alue of the field "acc_name" is equal to the alue of the field "acc_eff_name". --> <Conditional type="exclude"> <Field name="acc_name" name2="acc_eff_name" /> </Conditional> Filter definitions Following are seeral examples of log router filter definitions. The examples show two types of conditional elements (include and exclude), as well as the Field elements options: alue and name2. Some of these filters are contained in the set of standard filters that is in the file /opt/pdos/etc/pdoslrd.xml.template. Note: The audit log consolidation application supports a limited wildcard capability on the alue option of a Field element. You can use alue="*xyz", alue="xyz*", or alue="*xyz*", but not alue="abc*xyz". You can get the equialent of abc*xyz by haing two Field elements in the Conditional element: one with alue="abc*" and the other with alue="*xyz" You can use the question mark character (?) to match any character, but you cannot use the question mark and asterisk (*) together. Thus, alue="a?b" matches "azb", "a1b", "aab", for example. You can hae multiple question mark characters in a single alue (for example, alue="a?c?e?"). Wildcard characters are not supported on the name2 option of a Field element. They are only supported in the alue option. Chapter 4. The log router daemon 103

120 <!--Include only login denies --> <Filter name="login-deny"> <Conditional type="include"> <Field name="resource_type" alue="login"/> <Field name="iew" alue="d"/> </Conditional> </Filter> <!--Include only logins as root --> <Filter name="root-login> <Conditional type="include"> <Field name="resource_type" alue="login"/> <Field name="acc_name" alue="root"/> </Conditional> </Filter> <!--Include only non-root logins --> <Filter name="non-root-login"> <Conditional type="exclude"> <Field name="acc_name" alue="root"/> </Conditional <Conditional type="include"> <Field name="resource_type" alue="login"/> </Conditional> </Filter> <!--Include only records where the accessor effectie name is different from the accessor name. This indicates a user has changed to another user at some point in the past. This filter allows you to focus on all such actiity. --> <Filter name="su"> <Conditional type="exclude"> <Field name="acc_name" name2="acc_eff_name"/> </Conditional> </Filter> <!--Include only records where an account has been locked; either following the "three strikes and you re out" rule or using administratie action. --> <Filter name="account-locked"> <Conditional type="include"> <Field name="eent_id" alue="2"/> </Conditional> <Conditional type="include"> <Field name="eent_id" alue="3"/> </Conditional> </Filter> <!--Include only file access failures in the /etc directory. --> <Filter name="etc-file-failures"> <Conditional type="include"> <Field name="resource_type" alue="file"/> <Field name="iew" alue="d"/> <Field name="sys_res_name" alue="/etc/*" /> </Conditional> </Filter> <!--Include only records where a file has been marked untrusted. --> <Filter name="file-untrust" <Conditional type="include"> <Field name="eent_id" alue="22" /> </Conditional> </Filter> <!--Include only records where AMOS has entered isolation mode. --> <Filter name="isolation" <Conditional type="include"> <Field name="eent_id" alue="12" /> </Conditional> 104 IBM Tioli Access Manager for Operating Systems: Administration Guide

121 </Filter> <!--Include only records where a remote access attempt has failed due to Network Incoming Policy. --> <Filter name="incoming" <Conditional type="include"> <Field name="resource_type" alue="netincoming" /> <Field name="iew" alue="d" /> </Conditional> </Filter> Channels The following section describes the supported channel types for this release. There is one input channel type, LRD_AuditInput, and three output channel types: LRD_FileOutput, LRD_ Output, and LRD_NetOutput. Channel types LRD_AuditInput Reads the Tioli Access Manager for Operating Systems audit log (the default is /ar/pdos/audit/audit.log*) and formats the audit records into a form that allows filtering to be performed by the output channels. LRD_FileOutput Performs filtering, formats records for output, and writes records to a text file on the local host. LRD_ Output Performs filtering, formats records for output, and sends records to the specified address. LRD_NetOutput Performs filtering, formats records for output, and sends records to the pdacld process on a remote host. Using the channel types The log router channels are specified in the log router control file (/opt/pdos/etc/pdoslrd.xml) LRD_AuditInput There must be one and only one input channel specified in the log router control file. The only input channel type currently supported is LRD_AuditInput. This channel reads audit records from the Tioli Access Manager for Operating Systems audit log. The audit log consists of all files of the form audit.log* in the directory /ar/pdos/audit. The file audit.log is the latest file and all other files with names that start with audit.log are archied ersions. When the audit.log file reaches a certain size, it is rolled oer or archied into a file of the form audit.log.yyyy-mm- DD-hh-mm-ss. When the pdoslrd daemon is started, the input channel code looks for a file of the form input_channel_name.lrp in the directory /ar/pdos/pdoslrd, where input_channel_name is the name of the input channel in the log router control file. An example name could be input.lrp. If the file exists, it contains the timestamp and uniqifier of the last record processed during a preious inocation of pdoslrd. The input channel code will search the audit.log* files in /ar/pdos/audit until it finds an audit record with a timestamp and uniqifier that makes it later than the alues in the file input_channel_name.lrp. It starts reading audit records at this record. This mechanism allows the pdoslrd daemon to be shut down and restarted Chapter 4. The log router daemon 105

122 without losing its place in the audit log. If the input channel fails to find the file input_channel_name.lrp, it starts reading the audit log at the first record of the oldest file of the form audit.log*. Note: The uniqifier is a Tioli Access Manager for Operating Systems audit record field. It is used to distinguish between audit records that hae identical time stamps. An audit record will hae a non-zero uniqifier only if it was generated during the same second as the preious audit record. In addition, a non-zero uniqifier will always be one greater than the uniqifier of the preious audit record. If you iew an audit output file and see that this is not the case, it means that some records hae been filtered out. LRD_FileOutput This channel type performs filtering and writes records to a local file. The main use of this channel type is to proide a real-time iew of audit records. A system administrator who wants to iew the audit records as they are produced in as close to real time as is possible can issue a tail f command on the local file, and then iew the audit records as they are generated (with a slight delay). This is likely a practice that will only be done temporarily to gauge the current audit output. It could be done: to track a particular eent or group of eents prior to or just after making a change in the audit leel to test the effect of arious filters in the pdoslrd.xml file. LRD_ Output This channel type performs filtering and writes records to an address. The main use of this type of channel is to allow system administrators to monitor ery specific audit eents that occur infrequently. It is expected that this type of channel be highly filtered, meaning that only a few audit eents actually get sent through . If the channel is not highly filtered, the address might be oerwhelmed with a huge number of eents, which could also slow the other output channels down. The kind of filter used on this channel type is, therefore, ery important. An example of a filter that might be used here is one that filters out all eents except login denies, that is, audit eents that were generated when a user attempted to log in to a system and was denied access. LRD_NetOutput This channel type performs filtering and sends records to a remote host, which is running the Tioli Access Manager authorization serer, pdacld. The main use of this type of channel is to proide the endpoint component of the communication. The audit log consolidation functionality refers to one or more endpoint machines sending audit eents to the pdacld serer for archial purposes. Proiding this functionality is the main reason the log router was deeloped. The functionality is performed on endpoints by haing an input channel of LRD_AuditInput and an output channel of LRD_NetOutput, which sends formatted audit records to the pdacld serer using the Tioli Access Manager remote logging APIs. On the pdacld serer, the collection function is performed by the Tioli Access Manager remote logging serices aailable through pdacld. This collection requires an entry under the aznapi-configuration stanza in the file /opt/policydirector/etc/ialcd.conf similar to the following: [aznapi-configuration] logcfg = remote.channel_name:file path=/ar/policydirector/pdacld/amos_collection where channel_name is the name of the LRD_NetOutput channel on the endpoint machines (for example, netout-admin). 106 IBM Tioli Access Manager for Operating Systems: Administration Guide

123 In general, the pdacld serer will receie audit records from seeral endpoint machines and store them in a single collection file. There is, howeer, a facility for the serer to store records from each endpoint into a separate collection file. To enable this facility, you must ensure that each endpoint hostname appears in the ialcd.conf file as in the following example: [aznapi-configuration] logcfg = remote.channel_name.hostname1:file \ path=/ar/policydirector/pdacld/hostname1/amos_collection logcfg = remote.channel_name.hostname2:file \ path=/ar/policydirector/pdacld/hostname2/amos_collection In this example, records from endpoint hostname1 will be stored in one file and records from endpoint hostname2 will be stored in another. If pdacld is being used solely to receie audit records, then the following line should be included in the ialcd.conf file under the aznapi-configuration stanza: mode = remote Log router audit record fields Including this line preents pdacld from receiing Tioli Access Manager database replicas. The log router audit record fields include those fields that can be: Displayed when output is directed to a local file Written to a collection file Used in filter definitions Supported fields The log router is compatible with the current Tioli Access Manager for Operating Systems auditing code. The current Tioli Access Manager for Operating Systems audit.log format is presered. The keyalue, concise, and erbose formats of the log router are the same as the pdosaudiew formats. The set of audit record fields supported by the log router includes the following: All the fields in the concise format of the pdosaudiew tool. These are the same as in the keyalue format. This means all the fields in the three audit record types: general, trace, and logout are included. These record types are described in Chapter 7, Auditing, on page 191. The host_name field. This is the name of the host that generated the audit record. The local domain name. Supported field alues Seeral audit record fields hae a erbose alue and a concise alue or keyalue when displayed by the pdosaudiew command. For example, the erbose alues for the audit_outcome field are Success and Failure, whereas the concise alue or keyalue are S and F. All of the alues needed for the concise and keyalue formats are supported. All of the erbose alues are supported except for the eent_id and qualifier fields, which are in numeric form. The numeric alues for these two fields are described in Chapter 7, Auditing, on page 191. Chapter 4. The log router daemon 107

124 Supported formats The supported formats are as follows: Concise format (of the pdosaudiew tool). Keyalue format (of the pdosaudiew tool). Verbose format (of the pdosaudiew tool). Network output format. This consists of the fields and alues of the concise format plus the host_name field. output format. This is the same as the pdosaudiew erbose format. Field table The following table shows all of the fields and alues supported by the log router. The first column shows the field name defined in Chapter 7, Auditing, on page 191. The second column shows the name used by the log router. The log router field names are used in Field elements. The third column shows the name of the field in the keyalue format. These names can also be used in Field elements. The fourth column shows the formats that use the field. C means the field is used by concise (and keyalue). E means the field is used by the format (Channel type = LRD_ Output). N means the field is used by the network output format (Channel type = LRD_NetOutput). Audit Record Field Heading Log Router Field Name Keyalue Field Name Used By --- host_name --- E N Local Domain local_domain LD E N Timestamp time_stamp TS C E Audit Eent Identifier eent_id E C E N Audit View iew V C N Audit View iew_erb --- E Audit Reason reason R C N Audit Reason reason_erb --- E Audit Resource Type resource_type RT C E N Accessor Name acc_name AN C E N Accessor Effectie Name acc_eff_name AEN C E N Audit Action action A C E N Audit Permissions permissions P C N Audit Permissions permissions_erb --- E Audit Qualifier qualifier Q C E N Policy Branch Name branch_name PBN C E N Protected Object Name prot_obj_name PON C E N System Resource Name sys_res_name SRN C E N Surrogate Name sname SN C E N 108 IBM Tioli Access Manager for Operating Systems: Administration Guide

125 Audit Record Field Heading Log Router Field Name Keyalue Field Name Network Remote Host Identifier net_rem_host_id NRH C E N Network Protocol net_protocol NP C E N Network Serice net_serice NS C E N Login Location Identifier login_location_id LL C E N Accessor Processor ID accessor_pid APID C E N *Running Program Protected Name *Running Program System Resource Name Sudo Command and Arguments run_prog_prot_name RPPN C E N run_prog_sys_name RPSN C E N sudo_cmdargs SC C E N Sudo User Name sudo_user SU C E N Sudo Flags sudo_flags SF C E N Additional Parameters param AP C E N TCB Changed Data Attr Flags chg_attr_flags CDAF C E N Policy Epoch policy_epoch PE C E N Policy Version Number policy_ersion PVN C E N Audit Outcome outcome O C N Audit Outcome outcome_erb --- E Audit Fail Status fail_status FS C E N Audit Uniqifier uniqifier UQ C E N Used By *Protected Resource Specification *Accessed Resource Specification prot_res_spec PRS C E N acc_res_spec ARS C E N *The audit record fields Running Program Protected Name and Running Program System Resource Name are aailable when you are iewing general audit records; the fields Protected Resource Specification and Accessed Resource Specification are aailable when you are iewing trace audit records. Encoded field alues eent_id iew Field Possible alues This is a decimal number. The meaning of each number is listed in Table 48 on page 208. This is a single character, which will be one of the following: P permit D deny A admin I info T trace W warning Chapter 4. The log router daemon 109

126 Field Possible alues reason This is a decimal number from 1 to 5: outcome resource_type action qualifier 1 global audit 2 resource audit 3 global warning 4 resource warning 5 user audit This is one character: S success F failure This is one of the following strings: Azn Process TCB Cred Policy File Login Logout TraceExec TraceFile Password NetIncoming NetOutgoing Surrogate Sudo This is one of the following strings: Check Access Add Delete Change Retriee Apply Trust Untrust Start Stop Register Trace Isolated Not Isolated Login Logout Enable Disable This is a decimal number. The meaning of each number is listed in Table 49 on page IBM Tioli Access Manager for Operating Systems: Administration Guide

127 Field Permissions Possible alues This is a string of characters (for example, rwx). r read w write x execute o change ownership D change directory p change permission R rename N create d delete U utime K kill L login C connect G surrogate l readdir T traerse Log router output formats There are three log router output channels: Local file output: LRD FileOutput Output: LRD Output Network output: LRD Output Local file output LRD_FileOutput When records are routed to a local file (Channel type= LRD_FileOutput), the user can specify the output format to be concise, keyalue, or erbose. These are the same as the concise, keyalue, and erbose formats supported by the pdosaudiew tool. output LRD_ Output When records are routed to (Channel type=lrd_ output), the user can specify the output format to be concise, keyalue, or erbose. One message is sent for each audit record. It is expected that output will be highly filtered to reduce the number of audit records sent. For example, an administrator might select on only denies to be sent to . The following is an example of output: Subject: audit record notification The following audit record was sent by the log router daemon on host swing in local domain Default: Timestamp Audit Eent Audit View Audit Reason Audit Resource Type Accessor Name Accessor Effectie Name Audit Action Audit Permissions Audit Qualifier Policy Branch Name Mon 29 Oct :35:45 PM CST An authorization decision was made. Permit Global Audit File root root Check access read All resource policy checks permitted access. bt Chapter 4. The log router daemon 111

128 Protected Object Name File/opt/pdos Systems Resource Name /usr/lib/liblpm.so Accessor Process ID 1233 Running Program System Resource Name /usr/sbin/in.telnetd Audit Outcome Success Audit Uniqifier 1 Network output LRD_NetOutput When records are written to a remote host, the output channel used is LRD_NetOutput. The pdacld daemon on the serer machine will write the records it receies on the network to a collection file without modifying them in any way. Thus, the network output record format is identical to the collection file format. The fields of the collection file format include the host_name field, the local_domain field, and all the fields in the pdosaudiew concise format with one exception: the timestamp field in the collection file format is in a language neutral format, while the timestamp field of the pdosaudiew concise (and keyalue and erbose) format is dependent on the local code page. All of the fields of the network output record are conerted to UTF-8 before being sent oer the network. The number of endpoint machines that a single pdacld serer can serice depends on many ariables. The leel of auditing being performed is ery important. If only login denies are being sent, then the serer should be able to serice a ery large number of endpoints. If each endpoint is generating a ery large number of audit records, then the serer might be able to handle only a few endpoints. Of course, a great deal also depends on the relatie power of the machines inoled. It is assumed that pdacld serer machines will be high-end machines when there is considerable auditing is being done or a large number of endpoints are being sericed. File rolloer The Channel element has a rolloer_size option. When an output file reaches this size (in bytes), a rolloer will be performed. This applies only to LRD_FileOutput channels. A alue of zero means the file will grow indefinitely. File rolloers will be performed in the same manner as the audit.log is done. That is, the file will be renamed, and the new name will hae the date and time as a suffix. For example, an output file named auditout would be renamed to something like auditout The Channel element also has a max_files option. This option indicates the maximum number of rolloer files that will be generated. If this number is reached, the last file is not rolled oer, but grows without bound. If the max_files option is zero, there is no limit on the number of rolloer files. Collection files can also be rolled oer. This option is specified (in bytes) in the ialcd.conf file on the pdacld serer, as shown in the following example: logcfg = remote.netout.aushat12:file path = /home/amos/collection,rolloer_size= Note: This option must be entered as a single line. Output compression The Channel element has a compress option. This determines whether the output is compressed or not. This applies only to LRD_NetOutput channels. If the compress option is selected, the records will be uncompressed on the pdacld serer 112 IBM Tioli Access Manager for Operating Systems: Administration Guide

129 before being written to the collection file. Thus, the compress option reduces the amount of data sent oer the network, but it does not affect the contents of the collection file. Chapter 4. The log router daemon 113

130 114 IBM Tioli Access Manager for Operating Systems: Administration Guide

131 Chapter 5. Administratie tasks This chapter explains the administratie tasks required to manage the Tioli Access Manager for Operating Systems runtime and illustrates performing those tasks using the command line. It describes: Establishing a consistent username space to ensure that the appropriate mapping exists between the natie username space and the Tioli Access Manager user registry Ongoing administration of Tioli Access Manager for Operating Systems including managing its processes, the Trusted Computing Base (TCB), the credentials cache, and the hostname look-aside database Monitoring the effect of authorization policy on a system, and backing up and restoring the Tioli Access Manager for Operating Systems configuration and database files This chapter proides an oeriew of the administratie tasks. See Chapter 8, Commands, on page 219 for detailed information about each command. Tioli Access Manager for Operating Systems administratie tasks also can be performed from the Tioli desktop. See Chapter 6, Tasks aailable from Tioli Desktop, on page 139 for details. Administering Tioli Access Manager for Operating Systems consists of the following tasks: Defining runtime administrators and auditors Establishing a consistent user name space on page 116 Tuning the configuration on page 118 Obtaining the policy branch membership report on page 120 Managing processes on page 121 Verifying policy on page 123 Managing the Trusted Computing Base on page 127 Managing login actiity and password management policy enforcement on page 130 Managing credentials on page 132 Determining the accessor identity on page 134 Configuring and managing the hostname look-aside database on page 136 Backing up and restoring configuration files and databases on page 137 Defining runtime administrators and auditors A Tioli Access Manager for Operating Systems runtime administrator is authorized to perform administratie tasks to manage the runtime enironment. To be a runtime administrator, you must be a member of both of the following groups. osseal-admin group in the Tioli Access Manager user registry osseal group in UNIX Copyright IBM Corp. 2000,

132 A Tioli Access Manager for Operating Systems auditor is authorized to perform audit-related tasks. To be an auditor, you must be a member of both of the following groups. osseal-auditors group in the Tioli Access Manager user registry ossaudit group in UNIX Auditors are authorized to run the pdosaudiew command and access the files in the /ar/pdos/audit and /ar/pdos/tec directories. It is recommended that all runtime administrators be made auditors as well. Establishing a consistent user name space When setting up a Tioli Access Manager for Operating Systems enironment, you must understand the relationship between a system s natie user registry and the Tioli Access Manager user registry. For Tioli Access Manager for Operating Systems, the Tioli Access Manager user registry has to be an LDAP-based user registry. When acquiring the credentials needed to make authorization decisions, Tioli Access Manager for Operating Systems maps a natie user ID to a Tioli Access Manager user. The user s natie user name is obtained from the system s natie user registry using this numerical ID. The natie user name is mapped directly to a Tioli Access Manager user of the same name. The Tioli Access Manager user defines the primary user information and group membership. This identity is used in Tioli Access Manager for Operating Systems authorization decisions. Note: The group membership in the natie user definition is not used in Tioli Access Manager for Operating Systems decisions. If there is no Tioli Access Manager user corresponding to the user s natie username, then the user is treated as unauthenticated when authorization decisions are made. Because of this relationship, all systems sharing the same Tioli Access Manager user registry should use a consistent and distinct natie username for each user in the enironment. The UNIX identity and its relationship to the Tioli Access Manager user identity on page 3 gies an example of this relationship. The pdosrgyimp command assists in the task of populating the Tioli Access Manager user registry. This task requires careful planning. Identifying users and groups Consider how you will define groups. Aligning groups with job functions, projects, or roles is useful for establishing ACLs using group entries instead of indiidual user entries. This helps simplify policy definition and management. It also aids in efficient ealuation of policy by IBM Tioli Access Manager for Operating Systems. First, identify which UNIX users and groups should be included in the Tioli Access Manager user registry. This step depends on the policy decisions you make for a particular enironment. For instance, you might set up the policy in such a way that objects are protected through access controls that restrict or allow access based on a few specific user credentials and unauthenticated credentials for most other users. In this case, only the specific users of interest need to hae Tioli Access Manager entries. All other users can run with unauthenticated credentials. 116 IBM Tioli Access Manager for Operating Systems: Administration Guide

133 Or, you might set up a more selectie policy to restrict access to specific users and groups. In this case, most, if not all, users need to hae Tioli Access Manager entries. Identifying duplicate user names Set up the registry: 1. Look at all of the machines that will belong to a Tioli Access Manager domain. 2. Identify duplicate user or group entries across multiple machines. 3. Resole any duplicate entries. The duplicates might represent the same person or group. For example, user maggie on machine A might represent the person Maggie Smith and user maggie on machine B might also represent the person Maggie Smith. Because user maggie represents the same person on both machines, only one Tioli Access Manager entry is needed. In other cases, the duplicates represent different users or groups. For example: user riley on machine A represents the person Riley Smith and user riley on machine B represents the person Riley Jones. Because the user riley represents two different people, two Tioli Access Manager entries are needed. The UNIX identity and its relationship to the Tioli Access Manager user identity on page 3 shows another example of duplication. To resole this duplication, the UNIX name of one of the users must be changed. Using pdosrgyimp After you hae identified the UNIX users and groups to be imported, use the pdosrgyimp command on each machine that has UNIX registry users and groups to be imported. See pdosrgyimp on page 257 for a description of the pdosrgyimp command. The pdosrgyimp command creates user entries for all UNIX users and groups found in the UNIX registry. Any newly created groups are also populated with the user entries corresponding to the members of the UNIX group. The syntax is as follows: pdosrgyimp -S o=tioli -l login-id If almost all of UNIX users or groups are to be imported, you can create an exclude file with a list of the users and groups to exclude. In this case, all UNIX users and groups found in the UNIX registry are imported except those listed in the exclude file. The syntax is as follows: pdosrgyimp -S o=tioli -l login-id -E excludefilename If only a few UNIX users or groups are to be imported, you can create an include file with a list of the users and groups to include. In this case only the UNIX users and groups listed in the include file are imported. The syntax is as follows: pdosrgyimp -S o=tioli -l login_id -I includefilename Use the u or g options to import UNIX users and groups separately. Take care when importing groups separately from users. When groups are populated, an attempt is made to add all non-excluded users to the group. In this case you can specify both the include and exclude files. List the group in the include file. List the users that are to be left out of the group in the exclude file. The syntax is as follows: pdosrgyimp -S o=tioli -l login_id -I includefilename -E excludefilename The pdosrgyimp command creates two files. The file pdosrgyimp.import contains a list of pdadmin commands that were successfully executed. The file pdosrgyimp.conflict contains a list of pdadmin commands that failed. Chapter 5. Administratie tasks 117

134 Tuning the configuration Most failures occur because an entry already exists or because the Tioli Access Manager serer is down. The pdosrgyimp.conflict file can be used to aid in conflict resolution. Instead of running the pdosrgyimp command again, modify the text in the pdosrgyimp.conflict file. Then pipe it directly to the pdadmin command: pdadmin -a login_id -p password < pdosrgyimp.conflict The -n option specifies that pdosrgyimp should generate a list of pdadmin commands without actually executing them. Use this option to test what actions would be taken before you do the import. You can use the -n option with any of the pdosrgyimp examples listed aboe. The list of pdadmin commands is saed in the pdosrgyimp.import file. Use the configuration command pdoscfg to reconfigure certain Tioli Access Manager for Operating Systems configuration parameters after the initial configuration. Changes made using pdoscfg take effect the next time Tioli Access Manager for Operating Systems is stopped and restarted. You can enable or disable autostart, global warning, limitation of network ACL inheritance, the use of a hostname look-aside and ID-to-name mapping. You can tune credentials cache management and monitor the Trusted Computing Base. You can also modify how the Tioli Access Manager for Operating Systems daemons handle the log files. The global audit leel can be set. You can refresh the certificate of the LDAP serer s Certification Authority if necessary. You can also use the pdoscfg command to delete parameters from the configuration files so that the daemons use default alues on the next restart. You cannot change the policy branch name and the suffix. To change these parameters, you must first use the pdosucfg command to unconfigure Tioli Access Manager for Operating Systems and then configure it again. pdoscfg on page 225 lists all the pdoscfg options. Tioli Access Manager for Operating Systems configuration information is kept in a set of configuration files, one for each daemon. The files are named daemon_name.conf. Another file, containing common configuration data is named osseal.conf. The configuration files hae stanzas containing sets of attribute=alue pairs. Table 40 and the following tables show which files contain which stanzas, and how the stanza attributes map to the pdoscfg command line options. You can enable or disable autostart, global warning, limitation of network ACL inheritance, the use of a hostname look-aside, and ID-to-name mapping. If an attribute is missing from a stanza, the default alue is used. Table 40. Attribute Equialents of pdoscfg Options in osseal.conf Stanza Attribute Option [audit] leel audit_leel permit_actions deny_actions [authorization] warning warning [cache] dns dns uid audit_permit_actions audit_deny_actions uid [policy] branch branch [ffdc] capture ffdc_capture 118 IBM Tioli Access Manager for Operating Systems: Administration Guide

135 Table 41. Attribute Equialents of pdoscfg Options for pdosd.conf Stanza Attribute Option [ldap] ssl-certificate ldap_ssl_cacert [pdoscfg] autostart autostart login-policy login_policy net-acl-limited net_acl_limited [pdosd] kmsg-handler-threads kmsg_hnd_threads log-entries pdosd_log_entries logs pdosd_logs init-wait-minutes pdosd_init_wait [credentials] admin-cred-refresh admin_cred_refresh cred-hold cred_hold user-cred-refresh user_cred_refresh critical-cred-refresh critical_cred_refresh cred-response-wait cred_response_wait critical-cred-group critical_cred_group [policy] refresh-interal refresh_interal [ssl] ssl-listening-port ssl_listening_port [tcb] interal tcb_interal max-checksum-file-size tcb_max_file_size monitor-threads tcb_monitor_threads tcb_nocrc_on_exec tcb_nocrc_on_exec tcb_ignore_ctime tcb_ignore_ctime Table 42. Attribute Equialents of pdoscfg Options in pdosauditd.conf Stanza Attribute Option [pdosauditd] log-entries pdosauditd_log_entries audit-logflush audit_logflush logs pdosauditd_logs audit-logsize audit_log_size Table 43. Attribute Equialents of pdoscfg Options in pdoswdd.conf Stanza Attribute Option [pdoswdd] log-entries pdoswdd_log_entries logs pdoswdd_logs Table 44. Attribute Equialents of pdoscfg Options in pdoslrd.conf Stanza Attribute Option [pdoslrd] log-entries pdoslrd_log_entries logs pdoslrd_logs Chapter 5. Administratie tasks 119

136 You can use both the pdoscfg and pdosctl commands for some configuration actions. The pdoscfg command is used to modify the configuration files. These modifications do not take effect until the next time Tioli Access Manager for Operating Systems is stopped and restarted. The pdosctl command dynamically changes Tioli Access Manager for Operating Systems while it is running. The changes take effect immediately and are not persistent when you restart. The following sections show both the pdoscfg options and the pdosctl options where appropriate. Limiting ACL inheritance for network policy The limitation of network access ACL inheritance can be enabled, allowing for more efficient authorization decisions on network accesses. Enabling this feature limits the inheritance of ACLs that are attached to resources in the OSSEAL namespace for network accesses, similar to file accesses. In the case of file accesses, there is an implicit permissie ACL attached at /OSSEAL/policy-branch/File at all times. In the case of network accesses, if the limited network access ACL inheritance is enabled, then there are implicit permissie ACLs attached at the /OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing resources in the OSSEAL namespace. This feature can be enabled using the pdoscfg command with the -net_acl_limited option: #pdoscfg net_acl_limited on or disabled using the flag: #pdoscfg net_acl_limited off Tioli Access Manager for Operating Systems administrators should be aware that enabling this feature means that any ACLs which are attached at /OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing will no longer apply to network accesses. Another effect of enabling this feature is that network accesses to which no specific policy applies (below these points in the OSSEAL namespace) will not generate audit permit eents, as they did in prior releases due to access control inherited from /OSSEAL/policy-branch/NetIncoming and /OSSEAL/policy-branch/NetOutgoing. Obtaining the policy branch membership report The Tioli Access Manager for Operating Systems configuration includes the creation of a unique LDAP group for each new policy branch. Each subsequent machine that is configured into a policy branch will be added as a member of the policy branch s LDAP group. You can obtain a branch membership report for each Tioli Access Manager for Operating Systems machine by using the pdadmin command or Tioli Web Portal Manager. To determine which machines are subscribed to a specific policy branch, enter: pdadmin> group show-members pdosd-branch/policy-branch To determine which policy branch a machine is configured to, enter: pdadmin> user show-groups pdosd/hostname 120 IBM Tioli Access Manager for Operating Systems: Administration Guide

137 Managing processes Then look for a group called pdosd-branch/policy-branch to find the branch. This section tells how to start, stop, and monitor Tioli Access Manager for Operating Systems processes. Starting Tioli Access Manager for Operating Systems Tioli Access Manager for Operating Systems can be started manually from the command line or automatically at system boot time. You should start Tioli Access Manager for Operating Systems automatically at system boot time to ensure proper enforcement of authorization policy. To start automatically at boot time, enter: pdoscfg autostart on When the system reboots, Tioli Access Manager for Operating Systems starts automatically. To disable automatic startup at boot time, enter: pdoscfg autostart off When the system reboots, Tioli Access Manager for Operating Systems will not start automatically. To start Tioli Access Manager for Operating Systems from the command line, enter: rc.osseal start Note: If this is the first time that Tioli Access Manager for Operating Systems is started after a system reboot, this command must be run as root to ensure that the kernel extension gets loaded correctly. By default, Tioli Access Manager for Operating Systems is configured to start automatically at system boot time when it is initially configured on a system. You can oerride the automatic start on the pdoscfg command line by specifying autostart off during initial configuration. Stopping Tioli Access Manager for Operating Systems You can stop Tioli Access Manager for Operating Systems from the command line. To stop all the processes and deactiate the kernel extension, enter: rc.osseal stop You can also use the pdosctl command to stop selected daemons. For example, you might want to stop the pdosauditid daemon and restart it with a different logging parameter. To stop daemons with pdosctl, use the k option and specify the daemon name. For example, to stop the pdosauditid daemon, enter: pdosctl -k pdosauditd The output is: pdosauditd shutdown. Use the command rc.osseal start to restart the daemon. Checking daemon status Use the pdosctl command to check whether the pdosd, pdosauditid, pdoswdd, pdoslpmd, and pdoslrd daemons are running. The -s option, when specified with no arguments, displays the status of each of the daemons. Use the -s option Chapter 5. Administratie tasks 121

138 followed by a daemon name to display the status of a single daemon. You can use the -s option multiple times on a single command line. You can use the -q option with the -s option. The -q option suppresses the messages generated by the -s option and sets the return code to 0 on success and 1 if any of the queried daemons are down. The q option makes it simpler to use pdosctl in a shell script. Enter: pdosctl -s The output is: pdosd is running normally pdoswdd is running normally pdosauditd is running normally pdoslpmd is running normally pdoslrd is running normally If the pdosd daemon is running in isolation mode, the output is: pdosd is running under abnormal conditions isolated from the user registry pdoswdd is running normally pdosauditd is running normally pdoslpmd is running normally pdoslrd is running normally Note: The pdosctl command does not affect the pdostecd daemon. Daemon log files Each Tioli Access Manager for Operating Systems daemon maintains a log file that records significant eents and error conditions. The records written to the log files contain a UTC timestamp, information identifying the Tioli Access Manager for Operating Systems code logging the message, the message classification, and the message text. The message classification indicates the seerity of the message and is NOTIFY, WARNING, ERROR, or FATAL. These log files are in the directory /ar/pdos/log and are named msg pdos-daemon-name.log. (This is a new naming conention beginning with Tioli Access Manager for Operating Systems, Version 4.1. Old log files will not be renamed.) The log files can be useful for diagnostic purposes. For more information about using the log files for diagnostic purposes, see the IBM Tioli Access Manager for Operating Systems Problem Determination Guide. Use the pdoscfg command to tune how the daemons handle the log files. For the supported daemon, either pdosd, pdosauditd, pdoswdd or pdoslrd, you can specify the number of entries that can be written to the log file before the log file is archied. You can also specify the number of log files to be written before recycling the first file. The default configuration is to neer archie the log files. Table 45. pdoscfg Options that Control the Daemon Log Files Log File msg pdosd.log msg pdoswdd.log msg pdosauditd.log Options that control the Log File pdosd_log_entries pdosd_logs pdoswdd_log_entries pdoswdd_logs pdosauditd_log_entries pdosauditd_logs 122 IBM Tioli Access Manager for Operating Systems: Administration Guide

139 Table 45. pdoscfg Options that Control the Daemon Log Files (continued) Log File msg pdoslpmd.log msg pdoslrd.log Options that control the Log File None pdoslrd_log_entries pdoslrd_logs Verifying policy Note: The pdostecd daemon maintains its log file in a separate directory and the pdoscfg command cannot be used to adjust its logging configuration. You should erify that the policies you set are effectie, and erify policy wheneer you change policy. You can use either warning mode or audit mode to erify policy. Using warning mode to erify policy You can check the effects of authorization policy on a system without enabling enforcement of the policy by enabling warning mode. If warning mode is enabled, an audit record is generated for accesses to resources that would normally be denied due to policy but are granted because of warning mode. View the audit log to determine if the current authorization policy is haing the desired effect. You can enable warning mode globally for all policy or for specific protected resources. Note: If you enable global warning, you hae no enforcement in effect. Make sure you enable enforcement again, when required. Enabling, disabling, and querying global warning mode To enable global warning mode immediately, enter: pdosctl w on To disable global warning mode immediately, enter: pdosctl w off To enable global warning mode to take effect the next time Tioli Access Manager for Operating Systems is restarted, enter: pdoscfg warning on To disable global warning mode to take effect at the next restart, enter: pdoscfg warning off To query the current global warning mode setting, specify the w with no arguments: pdosctl w The output is: The global warning mode setting is off Enabling, disabling, and querying resource warning mode To enable warning mode for a specific resource, set up a protected object policy (POP) with warning mode enabled and attach it to the protected resource. Access to a protected object that would normally be denied by access controls is granted if Chapter 5. Administratie tasks 123

140 a POP is attached or if inherited with warning mode enabled. An audit record is generated regardless of the audit leel setting in the POP or the global audit leel. Warning mode is disabled by default. For example, to enable warning mode for accesses to the protected object name /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com, enter: pdadmin> pop create sample_pop pdadmin> pop modify sample_pop set warning yes pdadmin> pop attach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com NetIncoming accesses using telnet from systems with hostnames that match the pattern *.company.com and that would normally be denied are now permitted. An audit record is generated that shows that access was permitted due to resource warning mode. To disable warning mode, set the warning attribute to no or detach the POP from the protected object name. If you are using other attributes in the POP for the object and you want to disable only the warning mode, leaing the other attributes intact, set warning mode to off: pdadmin> pop modify sample_pop set warning no Warning mode is now disabled. If you are using this POP only for warning mode or it is also controlling other protected objects for which you still want warning mode enabled, detach the POP from the protected object to disable warning mode for just that object: pdadmin> pop detach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com sample_pop To query the warning mode setting in a POP, enter: pdadmin> pop show pop_name Using auditing to erify policy Use the auditing tools to monitor the effects of authorization policy on a system. Auditing can be set globally, for a specific protected resource or on a per-user basis. This section describes how to use the global and resource-leel auditing since they are the most useful for erifying policy. The supported global audit leels useful for erifying policy are permit, deny, loginpermit, and logindeny. The supported resource audit leels useful for erifying policy are permit and deny. For global and resource-leel auditing, the permit and deny leels can be further qualified so that they are only in effect for specified OSSEAL actions, such as write. See Chapter 7, Auditing, on page 191 for more information about auditing. Use the pdosaudiew command to see the results of auditing. See pdosaudiew on page 220 for a description of the pdosaudiew command. You must be defined as a Tioli Access Manager for Operating Systems auditor to use the pdosaudiew command. See Defining runtime administrators and auditors on page 115 for details. Setting and querying the global audit leel To set the global audit leel that goes into effect at the next restart of Tioli Access Manager for Operating Systems, enter: pdoscfg audit_leel leel where leel is one of the supported global audit leels. The audit leels useful for erifying policy are the ones that audit authorization decisions: permit, deny, loginpermit, and logindeny. 124 IBM Tioli Access Manager for Operating Systems: Administration Guide

141 You can use the pdosctl command to set or reset the global audit leel during runtime. The -A option resets the current global audit leel to the specified alue. If multiple -A options are specified on a single command line, the global audit leel is set to all the specified alues. The -a option modifies the global audit leel by resetting just the specified audit leel. Multiple -a options can be specified on a single command line. To reset or modify the global audit leel, the -a and -A options are followed by an audit leel and the keyword on or off separated by a colon (:). If only the audit leel is specified without the keyword on or off, the alue on is assumed. Valid alues for audit leel are: all, none, permit, deny, loginpermit, logindeny, admin, erbose, info, trace_exec, and trace_file. To reset the current global auditing to specific leels immediately, enter: pdosctl A leel:[on off] To turn on additional global audit leels, enter: pdosctl a leel:[on off] To set the global audit leel to permit and deny, enter: pdosctl -A permit:on -A deny:on To add the admin deny audit leel to the global audit leel, enter: pdosctl -a admin deny:on Any audit leels currently enabled are still enabled. When they are specified with no arguments, the -a and -A options display the current global audit leel of the pdosd, pdoslpmd, pdoslrd, pdosauditd, and pdoswdd daemons. To query the global audit leel, enter: pdosctl -a The output is: pdosd has the following audit leels on: permit, deny, admin pdoswdd has the following audit leels on: permit, deny, admin pdoslpmd has the following audit leels on: permit, deny, admin pdoslrd has the following audit leels on: permit, deny, admin pdosauditd has the following audit leels on: permit, deny, admin Setting and querying the resource audit leel To set the audit leel for a specific resource, set up a POP with the audit leel set as desired and attach the POP to the protected object name. The audit leel specified controls under what circumstances an access to an object generates an audit record. The supported resource audit leels useful for erifying policy are the ones that audit authorization decisions: permit deny The default is to not hae an audit leel set. For example, to set an audit leel of permit and deny for accesses to the protected object name /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com using the POP sample_pop, enter: pdadmin> pop modify sample_pop set audit-leel permit,deny pdadmin> pop attach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com sample_pop Chapter 5. Administratie tasks 125

142 An audit record is generated for all NetIncoming accesses using telnet from systems with hostnames that match the pattern *.company.com. The audit record indicates whether the access was permitted or denied. To preent the generation of audit records, set the audit leel attribute to none or detach the POP from the protected object name. If you are using other attributes in the POP for the object and you only want to turn off the audit leel, leaing the other attributes intact, set the audit leel to none: pdadmin> pop modify sample_pop set audit-leel none If you are using this POP only for resource auditing or if it is also controlling other protected objects that you still want to audit, detach the POP from the protected object to disable warning mode for just that object: pdadmin> pop detach /OSSEAL/Default/NetIncoming/TCP/telnet/*.company.com To query the audit leel setting in a POP, enter: pdadmin> pop show pop_name Testing programs in an unauthenticated enironment Because administratie users usually hae Tioli Access Manager for Operating Systems credentials, it is difficult to test policy affecting users and enironments that do not hae Tioli Access Manager for Operating Systems credentials. The pdosunauth command spawns a shell that is treated as unauthenticated. See pdosunauth on page 274 for information about the pdosunauth command. You can use this shell to erify policy affecting unauthenticated users and enironments. If an optional command is specified, the spawned shell executes only the specified command. The following sequence is an example of pdosunauth usage: 1. Run the following command as root: psdoswhoami a The output is 0 root 2. Run the pdosunauth command to spawn a shell that will be treated as unauthenticated for IBM Tioli Access Manager for Operating Systems authentication decisions: pdosunauth 3. Run the pdoswhoami command again: psdoswhoami a The output is Unauthenticated Any other commands executed in this shell are treated as unauthenticated for the purposes of Tioli Access Manager for Operating Systems authorization decisions. This allows the root user to erify that the policy permits and denies access for unauthenticated users in the expected manner. Note: Use the pdosunauth command sparingly. Do not gie access to it to many users. 126 IBM Tioli Access Manager for Operating Systems: Administration Guide

143 Managing the Trusted Computing Base The set of files comprising a system s Trusted Computing Base (TCB) is defined under the policy branch that the system subscribes to. This set includes files explicitly defined as TCB resources and programs listed in any permit entries of the Access-Restrictions attribute for an ACL. The trust states and signatures of TCB files are maintained on a per-machine basis in the Object Signature Database. The pdosd daemon monitors the files in the Trusted Computing Base for changes to a file s signature. If the pdosd daemon detects that the signature has changed, the file is marked untrusted in the Object Signature Database. Authorization requests to execute an untrusted Trusted Computing Base file are denied. When a file s state is set to untrusted in the Object Signature Database, it remains untrusted until explicit administratie action is taken to retrust that file. You must retrust a Trusted Computing Base file after an updated ersion of the file has been installed on the system. Tuning the pdosd daemon s Trusted Computing Base monitoring The pdoscfg command has options for tuning Trusted Computing Base monitoring. The tcb_interal parameter is the interal in minutes that the entire Trusted Computing Base should be scanned for changes. Increasing this interal reduces the load of the Trusted Computing Base monitoring system but potentially increases the time before a change is detected. The tcb_max_file_size parameter is the maximum number of bytes considered significant in the calculation of a file s checksum. The tcb_monitor_threads parameter is the number of threads dedicated to monitoring the files. The tcb_ignore_ctime parameter causes the ctime to be ignored when performing Trusted Computing Base signature comparisons. When this option is enabled, a change in ctime does not cause the Trusted Computing Base resource to become untrusted. The tcb_nocrc_on_exec parameter causes the CRC data checksum that normally occurs as part of the authorization check associated with running an executable file that is registered in the TCB to be skipped. Enabling this option aoids performing the CRC check on large binary files. The alues for these parameters are stored in the /opt/pdos/etc/pdosd.conf file in the [tcb] stanza when Tioli Access Manager for Operating Systems is initially configured. You can use the pdoscfg command to change the parameters. The changes take effect the next time IBM Tioli Access Manager for Operating Systems is stopped and restarted on the system. See pdoscfg on page 225 for more information about the pdoscfg command parameters. Managing the object signature database Use the pdosobjsig command to check the current trust state of Trusted Computing Base files in the Object Signature Database. The l option can list all files, all trusted files, or all untrusted files in the database. By default, this produces a detailed list of objects. Use the n option to cause only the names of the objects to be listed. Chapter 5. Administratie tasks 127

144 Use the g option to display the state of a specific file. The pdosobjsig command can also modify the current trust state of a Trusted Computing Base file. Use the -c option or the -C option to check that the signatures of the objects found in the database hae not changed. If a signature change is detected, the object is marked untrusted. The -c option checks the signature of a specific object. The -C option checks the signature for all objects found in the database. Use both u and s together, or the S option alone to modify the state. The u parameter sets the state of a specific file to trusted or untrusted. The S parameter sets the state of all files to either trusted or untrusted. For example, you install a new executable, /usr/local/app/bin/examplebinarya, that you want to be part of the Trusted Computing Base: 1. Enter: pdadmin> object create \ /OSSEAL/<policy-branch>/TCB/Secure-Programs/usr/local/app/bin/examplebinaryA 2. If the file exists when it is defined in the TCB, it is marked trusted. If it does not exist at the time that it is defined, you must explicitly set the state to trusted: pdosobjsig u /usr/local/app/bin/examplebinarya s trusted If, in the future, you install an updated ersion of example binarya and take no action, then the Tioli Access Manager for Operating Systems Trusted Computing Base monitor will detect that the signature has changed and set the state to untrusted. No one can run this executable. To aoid this, explicitly retrust the updated examplebinarya: pdosobjsig u /usr/local/app/bin/examplebinarya s trusted Managing scheduled upgrades to files registered in the Trusted Computing Base When installing an upgrade to an application or to the operating system, take care if any files inoled in the upgrade are registered in the Trusted Computing Base. This ensures that the pdosd daemon will not unexpectedly mark a command or program untrusted the first time it is executed after the upgrade due to a signature change. The pdosobjsig -C command option proides a way to recheck all the objects in the object signature database. As part of the check, a new signature is calculated. If pdosobjsig detects that the signature has changed, the file gets marked untrusted in the object signature database. The pdosobjsig -l untrusted command can then be used to generate a list of all files that are marked untrusted. By default, this produces a detailed list, which includes the reason the file was marked untrusted. Use the -n option to hae only the names of the files listed. After an administrator erifies that the list of files now marked untrusted is appropriate due to the upgrade, the pdosobjsig -S trusted command can be used to mark all the files as trusted again; or the pdosobjsig -u objname -s trusted command can be used to mark indiidual files as trusted. The following example lists the steps to take when an application, whose binaries are registered in the Trusted Computing Base, is upgraded: 1. Prior to the upgrade, check for objects already marked untrusted in the database. If any files are listed, determine why these files hae been marked untrusted and take the appropriate action before continuing with the upgrade or keep the list for future reference. To obtain the current list of objects that are marked untrusted, use the following command: pdosobjsig -l untrusted> untrusted.output 2. Perform the application upgrade. 128 IBM Tioli Access Manager for Operating Systems: Administration Guide

145 3. After the upgrade is complete, recheck the files in the object signature database. This updates the signatures of any files that hae changed and marks these files as untrusted. To recheck the signatures of all the objects in the object signature database, use the following command: pdosobjsig -C 4. To get a list of all files that are now marked untrusted, use the following command: pdosobjsig -n -l untrusted > after.upgrade.untrusted.output 5. Verify that the list of untrusted files is the expected list based on what was contained in the application upgrade. Compare this list with the list of files produced in Step 1. When you are satisfied that detected signature changes are legitimate due to the upgrade, retrust all the objects marked untrusted, using the following command: pdosobjsig -S trusted Managing operating system upgrades Careful consideration must be gien when upgrading the operating system on machines running Tioli Access Manager for Operating Systems, since system files inoled in the upgrade might be registered in the Trusted Computing Base or might hae been modified when login actiity policy enforcement was enabled. The following example lists the steps to take when performing an operating system upgrade: 1. Prior to the operating system upgrade, check for objects already marked untrusted in the database. If any files are listed, determine why these files hae been marked untrusted and take the appropriate action before continuing with the operating system upgrade or keep the list for future reference. To obtain the current list of objects marked untrusted, use the following command: pdosobjsig -l untrusted 2. It is recommended that you shut down Tioli Access Manager for Operating Systems prior to starting the upgrade. Use the following command: rc.osseal stop It is also recommended that you temporarily disable login actiity policy enforcement. This will remoe the Tioli Access Manager for Operating Systems updates to system files, just in case these files are affected by the upgrade. Use the following command to disable login policy: pdoscfg -login_policy off If a system reboot will occur as part of the upgrade, disable autostart prior to doing the upgrade. This ensures that the pdosd daemon does not mark a ital system executable as untrusted due to a signature change caused by the upgrade. Use the following command to disable autostart: pdoscfg -autostart off 3. Perform the operating system upgrade. 4. After the upgrade is complete, system files that are part of the Trusted Computing Base and were changed due to the upgrade must hae their signatures updated in the object signature database. Use the pdosobjsig -C command to quickly recheck the signatures of all the objects in the object signature database. This will update the signatures of any files that hae changed and mark them as untrusted. 5. To get a list of all files that are now marked untrusted, use the following command: Chapter 5. Administratie tasks 129

146 pdosobjsig -n -l untrusted> after.upgrade.untrusted.output 6. Verify that the list of untrusted files is the expected list based on what was contained in the operating system upgrade. Compare this list with the list of files produced in Step 1. When you are satisfied that detected signature changes were legitimate due to the upgrade, retrust all the objects marked untrusted, using the following command: pdosobjsig -S trusted 7. Re-enable login policy and autostart if you disabled them in Step 2, using the following command: pdoscfg -autostart on -login_policy on 8. Reboot the system to restart Tioli Access Manager for Operating Systems. Rebooting will ensure that the kernel driers and the daemon will be actiated at the appropriate time during system startup. Managing login actiity and password management policy enforcement The Tioli Access Manager for Operating Systems Login Actiity and Password Management Policy is enforced on a per-machine basis based on the actiity of an account that is defined on the machine. The pdoslpadm command is used to iew and manage the state of login actiity and password management. Viewing account records As part of the login actiity policy, a local database maintains records for all users that hae logged in since login actiity policy was actiated. These records can be iewed using the -r option of the pdoslpadm command. To see all the records that are currently in the database, specify the -r option with no operand. # pdoslpadm r User (uid) State<: Time Locked> gbland(1114) Unlocked root(0) Unlocked uduck(1118) Unlocked Detailed information about an account can be displayed by using the -f option. To see details about the gbland and uduck user IDs: # pdoslpadm r f gbland uduck Account state for gbland, id 1114: Lock status: Unlocked Last successful login: Sun 02 Dec :53:01 PM CST Current grace logins: 0 Password change date: Thu 08 No :00:00 AM CST Login failure data: Concurrent logins(allowed): 0(0) Account state for uduck, id 1118: Lock status: Unlocked Last successful login: Sun 02 Dec :09:25 PM CST Current grace logins: 0 Password change date: Thu 04 Oct :00:00 AM CDT Login failure data: Failure record 1: TTY name: /de/pts/4 rhost name: bigser.mycomp.com ruser name: 130 IBM Tioli Access Manager for Operating Systems: Administration Guide

147 Failing pid: 657 (login) Failure time: Sun 02 Dec :04:22 PM CST Concurrent logins(allowed): 0(10) Locking and unlocking accounts User accounts can be locked or suspended due to iolations of login actiity policy. A Tioli Access Manager for Operating Systems administrator can also explicitly lock an account by using the -l option of the pdoslpadm command. To lock the account associated with the bsmith user ID and preent future logins, use the following command: pdoslpadm l bsmith To re-enable an account for login and reset any alues that are causing the account to be locked or suspended due to a past iolation of login actiity policy, use the u option: pdoslpadm u bsmith Password change date for user accounts The login actiity policy attempts to use the password change date data from the local system data. This information is often part of the shadow password data that is stored for locally defined user accounts on UNIX systems. Howeer, password change date data is not aailable in all enironments. On HP-UX systems that are not trusted secure systems and in enironments with a distributed user registry, such as NIS, NIS+, and DCE, the password change date data is not aailable. In enironments where the password change date data is not aailable, the Tioli Access Manager for Operating Systems administrator can explicitly set a password change date on a user account basis by using the -m option of the pdoslpadm command. This should be done for all user accounts on systems that hae policy in place that relies on the password change date data, such as a grace login policy or a minimum or maximum password lifetime policy. Creation of local user accounts with minimum password age policy The specification of a minimum password age policy might cause problems when new accounts are created for locally defined users. When a new user account is created, the password change date is set to the current date. When the new user attempts to login, Tioli Access Manager for Operating Systems does not allow a password change due to a iolation of the minimum password age policy. An administrator should perform the following steps to ensure that a new local user account with a password can be changed immediately by the user. 1. Create an account using the standard system tools, such as mkuser on AIX or useradd on Solaris. 2. Set the password change date using the pdoslpadm -m command so that the date is sufficiently old to allow the change of the password without iolating the current minimum password age policy in effect. If no date is specified with this option, the alue that is used is the current date minus the number of days specified in the MinPasswordDays attribute of the password policy. Chapter 5. Administratie tasks 131

148 This sequence permits the user to login and change the password without iolating login actiity policy. Configuring NIS for login actiity policy As preiously mentioned in Password change date for user accounts on page 131, login actiity policy in NIS enironments with a distributed user registry is complicated by the fact that password change date data is not maintained. The pdoslpadm -m command can be used to proide the password change data for indiidual accounts, but this can become an administratie burden. Managing credentials Tioli Access Manager for Operating Systems proides support that allows an administrator to configure an NIS serer to support password change dates, assuming that the password change dates are aailable from the system files used to build the NIS maps. The NIS clients also must be configured to request the password change data from the NIS serer. To configure the NIS serer to generate a new map that proides password change dates for all user IDs, enter the following command on the NIS serer: pdoslpadm c on n serer Note that this new map is generated from the same files as the passwd map that is sered by the NIS serer. The NIS administrator needs to create a cron job or other administratie task to ensure that the passwdchg map is regenerated eery time the passwd map changes. On the NIS clients, enter the following command to hae the NIS clients request the updated passwdchg map from the NIS serer: pdoslpadm c on n client To unconfigure this support on either the NIS client or the NIS serer, enter the command specifying the -c off option. Credentials are cached so that Tioli Access Manager for Operating Systems can make authorization decisions efficiently and also to ensure that it can function isolated from the Tioli Access Manager user registry. The pdosd daemon uses an in-memory cache and a disk cache. Tuning the credentials cache The pdoscfg command has options for tuning the pdosd daemon s credential cache: user_cred_refresh The number of minutes that a user s credentials can exist in the credentials cache before they are considered to be due for a refresh. The interal starts at the time the credential is cached. When the refresh interal is exceeded, the credential is refreshed. admin_cred_refresh The refresh frequency of the credentials associated with Tioli Access Manager for Operating Systems administratie users. This option enables you to manage the credentials refresh interal for administratie users independently of the general users. 132 IBM Tioli Access Manager for Operating Systems: Administration Guide

149 cred_hold The number of minutes that general user credentials can be kept in the credentials cache beyond the time of the user s last access. Credentials associated with general users are flushed from the cache after this interal. The credentials associated with administratie and critical system users are neer flushed from the cache. The cred-hold interal must be at least as long as the user-cred-refresh interal. critical_cred_refresh The refresh frequency for credentials associated with critical system users. This option enables you to manage the credential refresh interal for critical system users independently of the general users. It is specified in minutes. critical_cred_group The name of the Tioli Access Manager group containing all users who are to be treated as critical system users. This group must be created and populated by the system administrator. Credentials for users who are members of this group are neer remoed from the cache. System administrators should use this group to specify users who are critical to the system and programs running on it to function properly. Administratie users (members of the Tioli Access Manager osseal-admin group) do not need to be members of this group. cred_response_wait The minimum number of minutes that the pdosd daemon will wait for responses to credential requests from the IBM Tioli Access Manager user registry before entering isolation mode. The alues for these parameters are stored in the /opt/pdos/etc/pdosd.conf file in the [credentials] stanza when Tioli Access Manager for Operating Systems is initially configured. For most enironments, the default alues are probably sufficient. You can change the alue with the pdoscfg command but the changes do not take effect until the next time Tioli Access Manager for Operating Systems is stopped and restarted on the system. See pdoscfg on page 225 for more information about the pdoscfg command. Explicitly refreshing credentials Credentials are initially retrieed or refreshed from the Tioli Access Manager user registry when a user logs into a system using a supported and defined login program while Tioli Access Manager for Operating Systems is running. All authorization decisions made for operations performed by processes subsequently run by this user are made using these credentials. You can explicitly refresh the credentials of a user already logged into the system, or users can refresh their own credentials. The pdosrefresh command refreshes the cached credentials for the inoking user, specified users, or the entire cache, according to the options specified on the command line. A user can refresh current credentials by inoking the pdosrefresh command with no options. An administratie user can refresh another user s credentials by specifying the UID or name. You can specify multiple users in a single inocation of the command. An administratie user can also refresh all of the credentials in the cache with -C option. Assume that you change the group membership in the Tioli Access Manager user registry for the users sally and riley. To hae this change take effect immediately, the credentials associated with these users need to be refreshed. Chapter 5. Administratie tasks 133

150 1. To refresh the credentials of users sally and riley, enter: pdosrefresh n sally n riley 2. Users sally and riley can each refresh their credentials by entering: pdosrefresh 3. To refresh all the credentials in the cache, enter: pdosrefresh -C Explicitly destroying credentials The pdosdestroy command remoes the cached credentials of the specified users. A user can destroy the current credentials by inoking the pdosdestroy command with no options. You can remoe the credentials of another user by specifying the UID or name. You can specify more than one user on the command line. To destroy the credentials of the inoking user, enter: pdosdestroy To destroy the credentials of users sally and riley, the user whose UID is 300, enter: pdosdestroy n sally u 300 Determining the accessor identity You might need to explicitly check the Tioli Access Manager for Operating Systems accessor identity associated with the enironment of a user or of a running process. The pdoswhoami command displays the Tioli Access Manager for Operating Systems accessor information associated with the inoking user. The command, with no options, displays the Tioli Access Manager for Operating Systems username. The n option displays the inoking user s accessor ID. The a option displays both the username and ID. The l option displays the user s group membership, the time the credentials were last refreshed, the credentials refresh expiry, the time the credentials were last accessed, and the credentials hold time expiry. The pdoswhois command displays the Tioli Access Manager for Operating Systems accessor information associated with running processes specified by process IDs (pids). The list of pids must be specified last on the pdoswhois command line. For each pid specified, the accessor ID and username are displayed. If the l option is specified, then the group membership, the time the credentials were last refreshed, the credentials refresh expiry, the time the credentials were last accessed, and the credentials hold time expiry are also displayed. Examples of pdoswhoami and pdoswhois The user sally is logged into a system running Tioli Access Manager for Operating Systems. User sally can iew her own credentials by entering the command: pdoswhoami l The output is: 134 IBM Tioli Access Manager for Operating Systems: Administration Guide

151 106 sally The credential is associated with the following groups: osseal-testers osseal-deelopers The credential was last refreshed at Sat No 4 14:07: The credential refresh time expires at Sun No 5 02:07: The credential was last accessed at Sat No 4 14:07: The credential hold time expires at Sat No 11 14:07: User root, who is a Tioli Access Manager for Operating Systems administrator by default, enters the command: pdoswhoami l The output is: 0 root The credential is associated with the following groups: osseal-admin osseal-auditors The credential was last refreshed at Sat No 4 11:52: The credential refresh time neer expires. The credential was last accessed at Sat No 4 14:12: The credential hold time neer expires. You, an administrator, can determine what credentials are associated with the running processes whose process IDs are 1756 and 1806 by entering: pdoswhois The output is Pid, 1756, is running under the uid = 106, user name = sally. Pid, 1806, is running under the uid = 300, user name = riley. Accessor identity and the UNIX identity differences The Tioli Access Manager for Operating Systems accessor identity and the UNIX identity in effect for a user or a running process might be different. For example, issuing a su command might change a user s UNIX identity but does not change the user s Tioli Access Manager for Operating Systems accessor identity. Executing a setuid or setgid program might change the UNIX identity of the process but the Tioli Access Manager for Operating Systems accessor identity associated with the process will still be that of the inoker. For example, the user sally is permitted to perform a change ID operation to the root user and runs the /bin/su command to become the root user. The Tioli Access Manager for Operating Systems accessor identity associated with this user is still sally but the UNIX identity is the root user. First the user sally issues these commands: id uid = 106(sally) pdoswhoami a 106 sally /bin/su After issuing /bin/su: id uid=0(root) pdoswhoami a 106 sally Chapter 5. Administratie tasks 135

152 Configuring and managing the hostname look-aside database To eliminate the need to consult the natie naming serice for eery IP address or hostname lookup, Tioli Access Manager for Operating Systems maintains a hostname look-aside database. This database is populated at runtime as the lookups occur. The use of this database is enabled by default when Tioli Access Manager for Operating Systems is initially configured on a system. Configuring the database Use the pdoscfg command to disable the hostname look-aside database by specifying dns off. You can enable or disable the hostname look-aside database at any time with the pdoscfg command but the changes do not take effect until the next time Tioli Access Manager for Operating Systems is stopped and restarted. To enable the hostname look-aside database for the next restart, enter: pdoscfg dns on To disable the hostname look-aside database for the next restart, enter: pdoscfg dns off Managing the database Use the pdoshla command to manage the database. You might need to do this when cached information becomes obsolete due to changes in the natie naming serice. The pdoshla command adds, deletes, refreshes, and iews entries in the database. The l option lists the existing database entries; it can be qualified by specifying all, stale, or fresh. You can add an entry for a gien IP address by using the a option. The natie naming serice is used to resole the hostname unless the H option is used to specify the associated hostname. The entry s default time-to-lie alue is 6 hours (21600 seconds). Use the T option and explicitly specify the time-to-lie alue to oerride the default. The F option flushes the entire database. The -f option flushes stale entries from the database. The r option flushes the specified entry. Use the u option to refresh all the database entries and cause a natie name serice lookup to occur for each entry found in the database. Examples of using pdoshla The following are examples of using the pdoshla command. 1. To add an entry to the default database for IP address , enter: pdoshla a To iew all of the entries in the default database, enter: pdoshla l all The output is: # Internet Address Hostname test1.austin.lab.tioli.com office1.tioli.com test3.austin.lab.tioli.com 136 IBM Tioli Access Manager for Operating Systems: Administration Guide

153 3. To iew stale entries found in the default database, enter: pdoshla l stale The output is: # Internet Address Hostname test3.austin.lab.tioli.com 4. To flush stale entries from the default database, enter: pdoshla f 5. To refresh all entries found in the default database, enter: pdoshla u Backing up and restoring configuration files and databases The pdosbkup and pdosrstr commands back up and restore IBM Tioli Access Manager for Operating Systems configuration files and databases. Backing up configuration files and databases You should stop Tioli Access Manager for Operating Systems before backing it up. If the pdosbkup command is executed while the daemons are running, the state of some of the files can change during the backup. The pdosbkup command backs up all files and directories in the /opt/pdos/etc/pdosbkuplist file. If x is specified, the files and directories listed in the /opt/pdos/etc/pdosbkuplistx file are backed up. Subdirectories are traersed. By default, the backup file created is placed in a file with the date and timestamp appended to it in the form of: /ar/pdos/pdosbkup/pdosbkupddmmmyyyy.hh_mm_ss.tar. For example, a backup performed at 12:34:56 on Noember 19, 2001 would be named: /ar/pdos/pdosbkup/pdosbkup19no _34_56.tar Use the p option to change the directory in which the backup file is placed. Use the f option to change the backup file name. Examples of backing Up Tioli Access Manager for Operating Systems The following are examples of backing up Tioli Access Manager for Operating Systems: 1. To back up critical configuration files, enter: pdosbkup 2. To do an extended backup, enter: pdosbkup x Restoring Tioli Access Manager for Operating Systems The pdosrstr command restores Tioli Access Manager for Operating Systems files that were preiously saed using the pdosbkup command. Files are restored from the backup file specified by the f option. Example of restoring Tioli Access Manager for Operating Systems The following is an example of restoring from a backup file. 1. To restore files saed in the pdosbkup25oct _32_41.tar file, enter: pdosrstr f /ar/pdos/pdosbkup/pdosbkup25oct _32_41.tar Chapter 5. Administratie tasks 137

154 138 IBM Tioli Access Manager for Operating Systems: Administration Guide

155 Chapter 6. Tasks aailable from Tioli Desktop The tasks and jobs described in this chapter are aailable only if you hae installed the IBM Tioli Access Manager for Operating Systems Management Tasks component. For information on installing this component, see the IBM Tioli Access Manager for Operating Systems Installation Guide. If you did not install the Tioli Access Manager for Operating Systems Management Tasks component, the information in this section does not apply to you. Instead, you should consult Chapter 5, Administratie tasks, on page 115 for information on using the command line to administer Tioli Access Manager for Operating Systems. When the Tioli Access Manager for Operating Systems Management Tasks component is installed, a PDOS Tasks task library is made aailable to the Tioli desktop that allows you to manage Tioli Access Manager for Operating Systems and its daemons. The PDOS Tasks task library is located in the Policy Director Region policy region. Note: All of the Tioli Access Manager for Operating Systems Management Tasks run as root on the target system. The tasks rely on root s priileges as a Tioli Access Manager for Operating Systems runtime administrator. If the root user ID is remoed as a Tioli Access Manager for Operating Systems runtime administrator, the tasks must be modified to run as a different runtime administrator. In addition to the tasks proided with Tioli Access Manager for Operating Systems, you can create your own tasks and jobs. A job is a task for which the targets and output parameters are preconfigured. See the Tioli Management Framework User s Guide for more information about task libraries, tasks, and jobs. You can modify the default execution characteristics of a particular job, such as where the output of a job is displayed and on which machines the job will run. You can also specify whether a job runs serially on each machine, in parallel on all machines, or staged in groups of machines. Task oeriew When you run a task, you must explicitly specify the nodes on which the task will run. As a conenience, jobs hae been proided for those tasks that you typically run on all Tioli Access Manager for Operating Systems nodes. These jobs are configured to run on all the nodes that are subscribers of the Tioli Access Manager for Operating Systems profile manager (PDOS), except where noted. You can use the Subscribe PDOS Endpoints job to subscribe the Tioli Access Manager for Operating Systems managed nodes and endpoints to the PDOS profile manager. These tasks can be modified to run on selected subscribers. You can also create your own tasks and jobs. For example, you can create separate tasks to start and stop Tioli Access Manager for Operating Systems serers on specific nodes. See the Tioli Management Framework User s Guide for more information about task libraries, tasks, and jobs, and about creating your own tasks and jobs. Copyright IBM Corp. 2000,

156 The following table proides the authorization role information for each of the Tioli Access Manager for Operating Systems tasks and jobs. The context for each authorization role is the task library. Note: The acronym PDOS stands for Policy Director for Operating Systems, the former name of Tioli Access Manager for Operating Systems. The term has been retained in the task names in order to maintain compatibility with preious ersions of Tioli Access Manager for Operating Systems Management Tasks. Table 46. Authorization for IBM Tioli Access Manager for Operating Systems Tasks Task Name Add/Remoe PDOS Auditors/Administrators Backup PDOS Database Certificate Transfer Utility Configure PDOS Auditing Configure PDOS Caching Configure PDOS Logging Configure PDOS Login and Password Policy Configure PDOS Serer Configure PDOS TCB Display PDOS Hostname Cache Distribute Log Router Daemon Control File Import UNIX TCB Import UNIX Users and Groups Manage PDOS Credential Cache Manage PDOS Serer State Manage PDOS TCB Purge PDOS Hostname Cache Query Branch Membership Query PDOS Login and Password Policy Query PDOS Serer State Query PDOS TCB Restore PDOS Database Set PDOS Serer Audit Leel Set PDOS Serer Trace Leel Setup TEC Eent Serer for PDOS Show PDOS Auditing Configuration Show PDOS Auditors/Administrators Show PDOS Caching Configuration Show PDOS Logging Configuration Show PDOS Serer Audit Leel Show PDOS Serer Configuration Show PDOS TCB Configuration Start TEC Adapter Authorization Roles admin admin user admin admin admin admin admin admin admin user admin admin admin admin admin admin admin admin admin admin admin admin admin admin, senior, super admin admin admin admin admin admin admin admin 140 IBM Tioli Access Manager for Operating Systems: Administration Guide

157 Table 46. Authorization for IBM Tioli Access Manager for Operating Systems Tasks (continued) Stop TEC Adapter Task Name Subscribe PDOS Endpoints Update PDOS Hostname Cache Authorization Roles admin admin admin General information regarding wrunjob and wruntask You can use the wrunjob and wruntask commands to run the IBM Tioli Access Manager for Operating Systems tasks from a script, and you can use the wschedjob command to schedule jobs. In the following sections, each IBM Tioli Access Manager for Operating Systems task description includes the arguments required for wruntask and wrunjob. All arguments listed must be used, and they must be used in the order shown. For more information about the wruntask and wrunjob commands, as well as the wschedjob command for scheduling jobs, see the Tioli Management Framework Reference Manual. Add/Remoe PDOS Auditors/Administrators This task can be used to add or remoe users as Tioli Access Manager for Operating Systems auditors or administrators. To add a user as an administrator, you must make the user a member of the local UNIX group, osseal, and a member of the associated Tioli Access Manager group, osseal-admin. To add a user as an auditor, you must make the user a member of the local UNIX group, ossaudit, and a member of the associated Tioli Access Manager group, osseal-auditors. To remoe a user s priileges as an administrator, you should remoe the user from the osseal group. To remoe a user s priileges as an auditor, you should remoe the user from the ossaudit group. If you remoe the user from osseal-auditors or osseal-admin, you will remoe the user s auditor or administrator priileges on all Tioli Access Manager for Operating Systems machines. Both the Add and Remoe actions to osseal-auditors and osseal-admin require a Tioli Access Manager administrator s user name and password to be specified. Note: All of the Tioli Access Manager for Operating Systems Management Tasks run as root on the target system. The tasks rely on root s priileges as a Tioli Access Manager for Operating Systems runtime administrator. If the root user ID is remoed as a Tioli Access Manager for Operating Systems runtime administrator, the tasks must be modified to run as a different runtime administrator. See the Tioli Management Framework User s Guide for more information about task libraries, tasks, and jobs. The following window corresponds to the Add/Remoe PDOS Auditors/Administrators task: Chapter 6. Tasks aailable from Tioli Desktop 141

158 Figure 2. Add/Remoe PDOS Auditors/Administrators Task Window Use the following steps to perform this task: 1. If the user is to be added to or remoed from the osseal-auditors or osseal-admin group, you must specify the first two fields. 2. Specify the name of the user to be added or remoed. 3. Select the desired operation: Add or Remoe. 4. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Add/Remoe PDOS Auditors/Administrators l PDOS Tasks a pd_admin_id a pd_admin_passwd a account a action a ossaudit a osseal_auditors a osseal a osseal_admin wruntask t Add/Remoe PDOS Auditors/Administrators l PDOS Tasks a pd_admin_id a pd_admin_passwd a account a action a ossaudit a osseal_auditors a osseal a osseal_admin h task_endpoint where: pd_admin_id Specifies the name of a Tioli Access Manager Administratie account that 142 IBM Tioli Access Manager for Operating Systems: Administration Guide

159 will be used to perform the Add or Remoe action. This argument is required only if either osseal_auditors or osseal_admin is set to True. pd_admin_passwd Specifies the password of the administratie account. This argument is required only if either osseal_audits or osseal_admin is set to True. account action ossaudit Specifies the user account from which to add or remoe priileges. Completion of this parameter is required. Specifies whether to add or remoe priileges from the specified account. This alue must be either ADD or REMOVE. If this parameter is set to TRUE, then the user will be added to or remoed from the local UNIX group, ossaudit. This alue must be either TRUE or FALSE. osseal_auditors If this parameter is set to TRUE, then the user will be added to or remoed from the Tioli Access Manager group, osseal-auditors. This alue must be either TRUE or FALSE. osseal Backup PDOS Database If this parameter is set to TRUE, then the user will be added to or remoed from the local UNIX group, osseal. This alue must be either TRUE or FALSE. osseal_admin If this parameter is set to TRUE, then the user will be added to or remoed from the Tioli Access Manager group, osseal-admin. This alue must be either TRUE or FALSE. task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to back up the Tioli Access Manager for Operating Systems databases and configuration files to an optionally specified file name. The file name may be specified as a relatie or absolute path. If the path is relatie, it is assumed relatie to the directory /ar/pdos/pdosbkup. The file name may contain format characters supported by the date command. These characters will be automatically expanded. If not specified, the file name defaults to /ar/pdos/pdosbkup/pdosbkup%m%d%y.tar. By default, backup files can be restored on a machine that is configured as a Tioli Access Manager client. Extended backup files can be created to restore a machine to a working state in an isolated enironment where the Tioli Access Manager serer is not aailable. The following window corresponds to the Backup PDOS Database task: Chapter 6. Tasks aailable from Tioli Desktop 143

160 Use the following steps to perform this task: 1. Enter a name for the Tioli Access Manager for Operating Systems database backup file. This may be specified as an absolute or relatie path; if relatie, it is assumed relatie to /ar/pdos/backup. The file name can contain format characters as supported by the date command. These will be automatically expanded. If unspecified, the file name used is /ar/pdos/pdosbkup/pdosbkup%m%d%y.tar. 2. If an extended backup is required, check Perform extended backup. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Backup PDOS Database l PDOS Tasks a file_name a extended_backup wruntask t Backup PDOS Database l PDOS Tasks a file_name a extended_backup h task_endpoint where: file_name extended_backup task_endpoint Certificate Transfer Utility Figure 3. Backup PDOS Database Task Window Specifies the file name in which to store the database backup. If this alue is the empty string, the default name is used. Specifies whether or not to perform an extended backup. The alue is either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Before a managed node or endpoint can be installed with Tioli Access Manager for Operating Systems, it must hae the digital CA certificates needed to configure both the Tioli Access Manager runtime enironment and Tioli Access Manager for Operating Systems. Tioli Access Manager for Operating Systems requires the LDAP SSL certificate used by the LDAP serer for SSL communications as well as the CA certificate for 144 IBM Tioli Access Manager for Operating Systems: Administration Guide

161 the Tioli Access Manager policy serer. If the policy serer has not been configured to automatically download the CA certificate during configuration of the Tioli Access Manager runtime enironment, the certificate must be obtained manually from the policy serer. This task proides an easy method to transfer the two certificates to target systems. The two certificates must be placed in directories on a managed node. The certificates do not need to be in the same directory. The task itself generates tasks that will be run on each destination system selected. The following window corresponds to the Certificate Transfer Utility task: Figure 4. Certificate Transfer Utility Task Window Use the following steps to perform this task: 1. Enter the path name for the LDAP SSL certificate. This path name must be on the Tioli management region serer. It must be readable by the root user. 2. Enter the path name for the policy serer certificate. This path name must be on the Tioli management region serer. It must be readable by the root user. 3. Enter the path name for the Destination Directory on the target systems. It must be writable by the root user. 4. Specify the desired Destination Systems. 5. Click Okay to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Certificate_Transfer l PDOS Tasks a ldap_certificate a pd_certificate a dest_directory a dest_system [ a dest_system,...] Chapter 6. Tasks aailable from Tioli Desktop 145

162 wruntask t Certificate_Transfer l PDOS Tasks a ldap_certificate a pd_certificate a dest_directory a dest_system [ a dest_system,...] h task_endpoint Note: While the Tioli Access Manager for Operating Systems installation program requires that the installation images be put on a local directory, the certificates can be placed in a common network location. Use this task if you cannot use other methods, such as FTP, to transfer the certificates to a Tioli Access Manager for Operating Systems target system. where: ldap_certificate pd_certificate dest_directory dest_system task_endpoint Specifies the pathname of the LDAP SSL certificate. Specifies the pathname of the Tioli Access Manager serer certificate. Specifies the destination directory. Specifies the destination system. Destination systems must be specified as either system(endpoint) or system(managednode). Specifies the name of the managed node where the certificates to be transferred are stored. This task should not be run on an endpoint or profile manager. Configure PDOS Auditing This task allows the administrator to modify the Tioli Access Manager for Operating Systems configuration parameters related to auditing. Two parameters can be modified: the audit log size limit and the audit log flush frequency. If a alue is not specified, the configuration parameter is left unchanged. Changes can either be placed into effect immediately or can take effect at the next restart of Tioli Access Manager for Operating Systems. The following window corresponds to the Configure PDOS Auditing task: Figure 5. Configure PDOS Auditing Task Window Use the following steps to perform this task: 1. Enter alues for the parameters you want to change. Parameters with no alue set will be left unchanged. 146 IBM Tioli Access Manager for Operating Systems: Administration Guide

163 2. If Tioli Access Manager for Operating Systems should be restarted after making the configuration changes, check Apply changes immediately. Otherwise, changes will not take effect until the next restart of Tioli Access Manager for Operating Systems. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Configure PDOS Auditing l PDOS Tasks a apply_now a size a frequency wruntask t Configure PDOS Auditing l PDOS Tasks a apply_now a size a frequency h task_endpoint where: apply_now size frequency task_endpoint Indicates that Tioli Access Manager for Operating Systems should be restarted after the changes are made. This alue must be either TRUE or FALSE. Specifies the size limit for audit logs in bytes. If this alue is the empty string, no change is made. Specifies the frequency of flushes to the audit log in seconds. If this alue is the empty string, no change is made. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Configure PDOS Caching This task allows the administrator to modify the Tioli Access Manager for Operating Systems configuration parameters related to caching. Eight parameters can be modified: the refresh frequency of administrator credentials, the refresh frequency of user credentials, the critical system users group, the refresh frequency of critical system user credentials, how long to wait for a response from LDAP before going into isolation mode, how long to cache unaccessed user credentials, whether a hostname resolution cache should be used, and whether a username resolution cache should be used. If a alue is not specified, the configuration parameter is left unchanged. Changes can either be placed into effect immediately or can take effect at the next restart of Tioli Access Manager for Operating Systems. The following window corresponds to the Configure PDOS Caching task: Chapter 6. Tasks aailable from Tioli Desktop 147

164 Figure 6. Configure PDOS Caching Task Window Use the following steps to perform this task: 1. Enter alues for the parameters you want to change. If a alue is left unspecified, it will be left unchanged. The refresh interals and credential hold period are in minutes. 2. If Tioli Access Manager for Operating Systems should cache hostnames and IP addresses, check Cache hostname to IP address mapping. 3. If Tioli Access Manager for Operating Systems should cache user/group names and user/group IDs, check Cache username to uid/gid mapping. 4. If Tioli Access Manager for Operating Systems should be restarted after making the configuration changes, check Apply changes immediately. Otherwise, changes will not take effect until the next restart of Tioli Access Manager for Operating Systems. 5. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Configure PDOS Caching l PDOS Tasks a apply_now a admin_refresh a user_refresh a user_cred_hold a cache_hosts a cache_users a crit_cred_group a crit_cred_refresh a cred_response_wait wruntask t Configure PDOS Caching l PDOS Tasks a apply_now a admin_refresh a user_refresh a user_cred_hold a cache_hosts a cache_users a crit_cred_group a crit_cred_refresh a cred_response_wait h task endpoint 148 IBM Tioli Access Manager for Operating Systems: Administration Guide

165 where: apply_now admin_refresh user_refresh user_cred_hold cache_hosts cache_users crit_cred_group crit_cred_refresh Indicates that Tioli Access Manager for Operating Systems should be restarted after the changes are made. This alue must be either TRUE or FALSE. Specifies how often cached administrator credentials should be refreshed in minutes. If this alue is the empty string, no change is made. Specifies how often cached user credentials should be refreshed in minutes. If this alue is the empty string, no change is made. Specifies how long to cache unaccessed user credentials in minutes. This alue must be greater than or equal to the configured alues for the administrator and user credentials refresh interals. If this alue is the empty string, no change is made. Indicates whether hostname resolution should use a local cache. This alue must be either TRUE or FALSE. Indicates whether username resolution should use a local cache. This alue must be either TRUE or FALSE. Specfies the name of the Tioli Access Manager for Operating Systems group whose members are treated as critical system users. Specifies the amount of time (in minutes) between refreshes of the critical user credentials. cred_response_wait Specifies the amount of time (in minutes) to wait for a response from LDAP before going into isolation mode. task_endpoint Configure PDOS Logging Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to modify the Tioli Access Manager for Operating Systems configuration parameters related to logging. Eight configuration parameters related to logging can be modified. These parameters specify the number of log files and the maximum number of entries per log file to use for logging in the Tioli Access Manager for Operating Systems daemons, pdosd, pdoswdd, pdosauditd, and pdoslrd. If a alue is not specified, the configuration parameter is left unchanged. Changes can either be placed into effect immediately or can take effect at the next restart of Tioli Access Manager for Operating Systems. The following window corresponds to the Configure PDOS Logging task: Chapter 6. Tasks aailable from Tioli Desktop 149

166 Figure 7. Configure PDOS Logging Task Window Use the following steps to perform this task: 1. Enter alues for the parameters you want to change. If a alue is not specified, the parameter will be left unchanged. 2. If Tioli Access Manager for Operating Systems should be restarted after making the configuration changes, check Apply changes immediately. Otherwise, changes will not take effect until the next restart of Tioli Access Manager for Operating Systems. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: 150 IBM Tioli Access Manager for Operating Systems: Administration Guide

167 wrunjob Configure PDOS Logging l PDOS Tasks a apply_now a pdosd_logs a pdosd_entries a pdoswdd_logs a pdoswdd_entries a pdosauditd_logs a pdosauditd_entries a pdoslrd_logs a pdoslrd_entries wruntask t Configure PDOS Logging l PDOS Tasks a apply_now a pdosd_logs a pdosd_entries a pdoswdd_logs a pdoswdd_entries a pdosauditd_logs a pdosauditd_entries a pdoslrd_logs a pdoslrd_entries h task_endpoint where: apply_now pdosd_logs pdosd_entries pdoswdd_logs pdoswdd_entries Indicates that Tioli Access Manager for Operating Systems should be restarted after the changes are made. This alue must be either TRUE or FALSE. Specifies the number of log files to use for the pdosd daemon. If this alue is the empty string, the parameter is left unchanged. Specifies the number of entries to allow per log for the pdosd daemon. If this alue is the empty string, the parameter is left unchanged. Specifies the number of log files to use for the pdoswdd daemon. If this alue is the empty string, the parameter is left unchanged. Specifies the number of entries to allow per log for the pdoswdd daemon. If this alue is the empty string, the parameter is left unchanged. pdosauditd_logs Specifies the number of log files to use for the pdosauditd daemon. If this alue is the empty string, the parameter is left unchanged. pdosauditd_entries Specifies the number of entries to allow per log for the pdosauditd daemon. If this alue is the empty string, the parameter is left unchanged. pdoslrd_logs pdoslrd_entries task_endpoint Configure PDOS Login and Password Policy Specifies the number of log files to use for the pdoslrd daemon. If this alue is the empty string, the parameter is left unchanged. Specifies the number of entries to allow for the pdoslrd daemon. If this alue is the empty string, the parameter is left unchanged. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to configure parameters related to Tioli Access Manager for Operating Systems login and password policy. The following policy can be configured: Tioli Access Manager for Operating Systems login and password policy can be enabled or disabled. By default, the field is blank and does not change the current setting. A specified user account can be locked, unlocked, hae its login actiity records deleted, or hae the password change date set to the current date. Chapter 6. Tasks aailable from Tioli Desktop 151

168 The following window corresponds to the Configure PDOS Login and Password Policy task: Figure 8. Configure PDOS Login and Password Policy Task Window Use the following steps to perform this task: 1. You can enable, disable, or leae Tioli Access Manager for Operating Systems login and password policy at its current setting. 2. Specify the User account to be modified. 3. Select the operation you want to perform. 4. Specify whether to reset the date. 5. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Configure PDOS Login and Password Policy l PDOS Tasks a enable_login a account a action wruntask t Configure PDOS Login and Password Policy l PDOS Tasks a enable_login a account a action h task_endpoint where: enable_login Indicates whether or not to enable Tioli Access Manager for Operating 152 IBM Tioli Access Manager for Operating Systems: Administration Guide

169 account action Configure PDOS Serer Systems login and password policy processing. This alue must be either TRUE or FALSE. If this alue is the empty string, no change is made. If this parameter is not blank, then the action specified in the action parameter will be performed on the specified user account. Indicates what action to perform on the specified account. Valid alues are DELETE, LOCK, UNLOCK, and CHANGEDATE. task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to modify miscellaneous Tioli Access Manager for Operating Systems configuration parameters. Eight parameters can be modified: the port Tioli Access Manager for Operating Systems uses to receie notifications of policy updates how often (in minutes) policy refreshes occur whether system login and password restrictions are enabled the number of kernel threads used to handle authorization requests the certificate used to communicate and authenticate with the LDAP serer whether Tioli Access Manager for Operating Systems should be automatically started at system startup whether first failure data should be captured when a Tioli Access Manager for Operating Systems daemon dies whether to configure the Tioli Access Manager for Operating Systems log router daemon. If a alue is not specified, the configuration parameter is left unchanged. The following window corresponds to the Configure PDOS Serer task: Chapter 6. Tasks aailable from Tioli Desktop 153

170 Figure 9. Configure PDOS Serer Task Window Use the following steps to perform this task: 1. Tioli Access Manager for Operating Systems can be configured to receie policy update notifications on a specified port. If the Policy Update Notification Port is set to 0, then policy updates will not be receied by notification. If a alue is not specified, the parameter will be left unchanged. For Tioli Access Manager for Operating Systems, Version 4.1 and earlier, the security master password must be specified in order to change the port. The security master password is not required in Version Tioli Access Manager for Operating Systems can be configured to poll the Tioli Access Manager policy serer for policy updates. The Policy Update Polling Interal is specified in minutes, and a alue of 0 will disable policy update polling. If a alue is not specified, the parameter will be left unchanged. 154 IBM Tioli Access Manager for Operating Systems: Administration Guide

171 3. Tioli Access Manager for Operating Systems can be enabled or disabled to enforce system login and password restrictions. If a alue is not specified, the parameter will be left unchanged. 4. The number of kernel threads used to handle authorization requests can be changed. This alue must be positie. If a alue is not specified, the parameter will be left unchanged. 5. The LDAP SSL CA certificate can be changed by supplying the full pathname to a file containing the new LDAP certificate. If a alue is not specified, the parameter will be left unchanged. 6. Tioli Access Manager for Operating Systems can be configured to capture first failure data. 7. The startup behaior of Tioli Access Manager for Operating Systems can be changed with the Automatically start PDOS at system startup box. If a alue is not specified, the parameter will be left unchanged. 8. The configuration of the log router daemon can be changed with the Configure Log Router Daemon box. A Tioli Access Manager administrator name and password must be supplied in order to change the configuration. You can specify to which Tioli Access Manager local domain the log router daemon will be configured. If no domain is specified, the system will try to use the local domain that pdosd is configured to. 9. Click Execute and Close to perform the task. The Tioli Access Manager for Operating Systems instance will be restarted with the new configuration. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Configure PDOS Serer l PDOS Tasks a notification_port a password a refresh_interal a login_policy a threads a ldap_certificate a autostart a password a first_failure a lrd_config a lrd_local_domain a lrd_admin_name a lrd_admin_pwd wruntask t Configure PDOS Serer l PDOS Tasks a notification_port a password a refresh_interal a login_policy a threads a ldap_certificate a autostart a password a first_failure a lrd_config a lrd_local_domain a lrd_admin_name a lrd_admin_pwd h task_endpoint where: notification_port refresh_interal login_policy Specifies a port to use to receie policy update notifications. A alue of zero will disable policy update notifications. If this alue is the empty string, the parameter is left unchanged. A password must be specified to change this parameter. Specifies an interal in minutes that the Tioli Access Manager policy serer is polled for policy updates. A alue of zero will disable policy updates polling. If this alue is the empty string, the parameter is left unchanged. Specifies whether Tioli Access Manager for Operating Systems should enforce system login and password restrictions. This alue can be TRUE, FALSE, or the empty string. Chapter 6. Tasks aailable from Tioli Desktop 155

172 threads password ldap_certificate autostart first_failure lrd_config lrd_local_domain lrd_admin_name lrd_admin_pwd task_endpoint Specifies the number of kernel threads used to handle authorization requests. If this alue is the empty string, the parameter is left unchanged. Specifies the security master password. This password only needs to be specified in order to change the notification port for Tioli Access Manager for Operating Systems, Version 4.1 and earlier. Specifies a certificate to communicate and authenticate with the LDAP serer. A full pathname to a file containing the certificate must be specified. If this alue is the empty string, the parameter is left unchanged. A password must be specified to change this parameter. Specifies whether Tioli Access Manager for Operating Systems should be automatically started at system startup. This alue can be TRUE, FALSE, or the empty string. Indicates that first failure data should be automatically captured when a Tioli Access Manager for Operating Systems daemon dies. The alue must be either TRUE or FALSE. Specifies whether the Tioli Access Manager for Operating Systems log router daemon should be configured. This alue can be TRUE, FALSE, or the empty string. Specifies the Tioli Access Manager local domain name that the log router daemon will be configured to. If this alue is not specified, the system will try to use the local domain that pdosd is configured to. Specifies a Tioli Access Manager administrator name. Specifies a Tioli Access Manager administrator password. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Configure PDOS TCB This task allows the administrator to modify the Tioli Access Manager for Operating Systems configuration parameters related to the Trusted Computing Base (TCB). The following fie parameters can be modified: the number of monitoring threads, the delay interal (in seconds) between monitoring attempts, the maximum number of megabytes of a file to be used for calculating a checksum (TCB signature), whether to ignore a file s ctime in TCB signature comparisons, and 156 IBM Tioli Access Manager for Operating Systems: Administration Guide

173 whether to perform the CRC checksum calculation and comparison during execution authorizations. If a alue is not specified for the first three parameters, the configuration parameter is left unchanged. Changes can either be placed into effect immediately or wait until the next restart of Tioli Access Manager for Operating Systems. The following window corresponds to the Configure PDOS TCB task: Figure 10. Configure PDOS TCB Task Window Use the following steps to perform this task: 1. Enter alues for the parameters you want to change. If a alue is not specified, the parameter will be left unchanged. 2. If Tioli Access Manager for Operating Systems should be restarted after making the configuration changes, check Apply changes immediately. Otherwise, changes will not take effect until the next restart of Tioli Access Manager for Operating Systems. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Configure PDOS TCB l PDOS Tasks a apply_now a threads a interal a checksum_max_size a ignore_ctime a nocrc_on_exec wruntask t Configure PDOS TCB l PDOS Tasks a apply_now a threads a interal a checksum_max_size a ignore_ctime a nocrc_on_exec h task_endpoint where: apply_now threads Indicates that Tioli Access Manager for Operating Systems should be restarted after the changes are made. This alue must be either TRUE or FALSE. Specifies the number of threads used to monitor TCB objects. If this alue is the empty string, the parameter is left unchanged. Chapter 6. Tasks aailable from Tioli Desktop 157

174 interal Specifies the interal in seconds between monitoring sweeps of the TCB. If this alue is the empty string, the parameter is left unchanged. checksum_max_size Specifies the maximum number of megabytes of a file to be used when computing its checksum (TCB signature). The bytes are distributed throughout the file. If this alue is the empty string, the parameter is left unchanged. ignore_ctime nocrc_on_exec task_endpoint Display PDOS Hostname Cache If this parameter is set to TRUE (enabled), the ctime will be ignored in all TCB signature comparisons. A change in ctime will not cause the TCB resource to become untrusted. This alue must be either TRUE or FALSE. The default alue is FALSE. If this parameter is set to TRUE (enabled), the CRC data checksum calculation and comparison will be skipped on TCB signature checks during Tioli Access Manager for Operating Systems execution authorization processing. This alue must be either TRUE or FALSE. The default alue is FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to iew entries in the IP address/hostname translation cache used by Tioli Access Manager for Operating Systems. All stale entries, all alid entries, or both, might be displayed. The following window corresponds to the Display PDOS Hostname Cache task: Figure 11. Display PDOS Hostname Cache Use the following steps to perform this task: 1. Select the type(s) of entries to display: expired, alid, or both. 2. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: 158 IBM Tioli Access Manager for Operating Systems: Administration Guide

175 wrunjob Display PDOS Hostname Cache l PDOS Tasks a display_alid a display_stale wruntask t Display PDOS Hostname Cache l PDOS Tasks a display_alid a display_stale h task_endpoint where: display_alid display_stale task_endpoint Indicates that all alid entries should be displayed. This alue must be either TRUE or FALSE. Indicates that all stale entries should be displayed. This alue must be either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Distribute Log Router Daemon Control File A file, pdoslrd.xml, is used to specify the arious parameters necessary to run the Tioli Access Manager for Operating Systems log router daemon, pdoslrd. The format of this file must comply with the XML 1.0 specification. This task proides an easy method to distribute pdoslrd.xml to target systems. The file must be placed in a directory on a managed node. The task itself generates tasks that run on each destination system that you select. The following window corresponds to the Distribute Log Router Daemon Control File task: Figure 12. Distribute Log Router Daemon Control File Use the following steps to perform this task: 1. Enter the pathname for the pdoslrd.xml file. This pathname must be on the Tioli management region serer and it must be readable by the root user. 2. Specify the desired destination systems. 3. Click OK to perform the task. Chapter 6. Tasks aailable from Tioli Desktop 159

176 Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Distribute_Log_Router_Daemon_Control _File l PDOS Tasks a lrd_cont_file a dest_system [ a dest_system,...] wruntask Distribute_Log_Router_Daemon_Control _File l PDOS Tasks a lrd_cont_file a dest_system [ a dest_system,...] h task_endpoint where: lrd_cont_file dest_system task_endpoint Specifies the pathname of pdoslrd.xml Specifies the destination systems. Destination systems must be specified as either system(endpoint) or sytem(managednode). Specifies the name of the managed node where the file to be distributed is stored. This task should not be run on an endpoint or profile manager. Import UNIX TCB This task allows the administrator to populate the Trusted Computing Base (TCB) by recursiely searching the UNIX system for setuid/setgid programs. The administrator must specify the class of resources to populate: Immune-Surrogate-Programs, Secure-Files, Impersonator-Programs, or Immune-Programs. The default is Secure-Programs. Additionally, one or more directories to recursiely search may be supplied in the form of a comma-separated list. If desired, another list of directories to exclude from the search may be proided. A specific policy branch into which to populate may optionally be supplied. If omitted, the current subscribed policy branch is used. Also, you can choose whether to generate a script to update the TCB with records for the discoered files or simply report the discoered files. Finally, you can choose whether or not to add multiple entries to the TCB for hard links to files. The following window corresponds to the Import UNIX TCB task: 160 IBM Tioli Access Manager for Operating Systems: Administration Guide

177 Figure 13. Import UNIX TCB Task Window Use the following steps to perform this task: 1. Choose the category of files on which to search. 2. As an option, you can specify directories to be included or excluded from the search. 3. If the files discoered in the file system search should generate a script to update the TCB, check Generate update script. Otherwise, the found files will be reported in a window. 4. If files with hard links to them should generate multiple entries in the TCB, check Generate duplicate entry for hard links. Otherwise, one entry will be generated regardless of the number of links to the file. 5. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Import UNIX TCB l PDOS Tasks a class a branch a directories a excludes a duplicate_links a generate_script wruntask t Import UNIX TCB l PDOS Tasks a class a branch a directories a excludes a duplicate_links a generate_script h task_endpoint where: class branch directories excludes Specifies the class of TCB resource to create. This must be one of the classes listed aboe. Specifies into which policy branch to import TCB resources. If empty, the currently subscribed policy branch is used. Specifies a comma-separated list of directories to recursiely search. Specifies a comma-separated list of directories to exclude from the search. Chapter 6. Tasks aailable from Tioli Desktop 161

178 duplicate_links generate_script task_endpoint Indicates whether multiple entries should be generated for hard linked files. This alue must be either TRUE or FALSE. Indicates that a script should be generated to add the discoered files to the TCB. This alue must be either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Import UNIX Users and Groups This task allows the administrator to populate the Tioli Access Manager account registry using local UNIX account information. The users and groups proided in comma-separated lists are used to obtain account data from UNIX. Each list may be either Inclusie or Exclusie. An Inclusie list means only those specified users/groups should be imported. An Exclusie list means all users/groups except those specified should be imported. A list alue of * indicates all users. List entries must be user/group names, not UIDs/GIDs. An LDAP suffix that will be appended to created users/groups must be supplied. An administratie account in Tioli Access Manager and its password are also required to import data. You can specify how to import data for users/groups already existing in LDAP. If a user/group to be imported has a corresponding entry in LDAP, an administrator can specify whether to import information from LDAP or the local UNIX sources. Optionally, the administrator may choose to only report on the accounts that would be imported. For users, the administrator may specify whether accounts are created enabled (the default) or disabled. The administrator may also specify a default group for users without group membership and a default password (if empty, a random password is assigned). For groups, the administrator may specify the behaior when the group already exists in Tioli Access Manager. The administrator may specify that group entries be refreshed for groups that already exist in Tioli Access Manager. The following window corresponds to the Import UNIX Users and Groups task: 162 IBM Tioli Access Manager for Operating Systems: Administration Guide

179 Figure 14. Import UNIX Users and Groups You can specify a Tioli Access Manager local domain that the accounts will be imported to. If you do not specify a local domain, the system will try to use the domain that pdosd is configured to. Use the following steps to perform this task: 1. You must specify the first three fields in the Access Manager block. All other fields are optional. 2. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: Chapter 6. Tasks aailable from Tioli Desktop 163

180 wrunjob Import UNIX Users and Groups l PDOS Tasks a admin_id a admin_pwd a suffix a ldap_import a report_only a user_list a user_list_type a create_disabled a default_group a default_passwd a group_list a group_list_type a group_refresh a local_domain wruntask t Import UNIX Users and Groups l PDOS Tasks a admin_id a admin_pwd a suffix a ldap_import a report_only a user_list a user_list_type a create_disabled a default_group a default_passwd a group_list a group_list_type a group_refresh a local_domain h task_endpoint where: admin_id admin_pwd suffix ldap_import report_only user_list user_list_type create_disabled default_group default_passwd group_list group_list_type group_refresh local_domain task_endpoint Specifies the name of a Tioli Access Manager administratie account to use to import entries. Completion of this argument is required. Specifies the password of the administratie account. Completion of this argument is required. Specifies the LDAP suffix to append to created users and groups. Completion of this argument is required. Indicates that the user or group should be imported from LDAP if it exists there and it is not already a Tioli Policy Director user or group. This alue must be either TRUE or FALSE. Indicates that the task should only report what it would do and not update the database. This alue must be either TRUE or FALSE. Specifies a comma-separated list of usernames to import (or exclude from import). Indicates whether the list is of users to include or exclude. This alue must be either Inclusie or Exclusie. Indicates that users should be created disabled. This alue must be either TRUE or FALSE. Specifies a default Tioli Access Manager group to which to add created users if they hae no group membership. Specifies a default password to assign to the created users. Specifies a comma-separated list of group names to import, or exclude from import. Indicates whether the list of groups is inclusie or exclusie. This alue must be either Inclusie or Exclusie. Indicates whether, if the group already exists, the group membership should be updated to match the UNIX group. This alue must be either TRUE or FALSE. Specifies a Tioli Access Manager local domain that the accounts will be imported to. If you do not specify a local domain, the system will try to use the domain the pdosd is configured to. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. 164 IBM Tioli Access Manager for Operating Systems: Administration Guide

181 Manage PDOS Credential Cache This task allows the administrator to refresh and/or destroy entries in the credential cache used by Tioli Access Manager for Operating Systems. The administrator may specify two comma-separated lists, one to indicate credentials to refresh and the other to indicate credentials to destroy. Either is optional. List entries may be either a UID or a username. The following window corresponds to the Manage PDOS Credential Cache task: Figure 15. Manage PDOS Credential Cache Task Window Use the following steps to perform this task: 1. Enter a comma-separated list of users and/or UIDs whose cached credentials should be refreshed. An empty list indicates no credentials should be refreshed. An asterisk (*) indicates that all users currently in the credential cache should be refreshed. 2. Enter a comma-separated list of users or UIDs whose cached credentials should be destroyed. An empty list indicates no credentials should be destroyed. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Manage PDOS Credential Cache l PDOS Tasks a refresh_list a destroy_list wruntask t Manage PDOS Credential Cache l PDOS Tasks a refresh_list a destroy_list h task_endpoint where: refresh_list destroy_list task_endpoint Specifies UIDs/usernames for which the cached credential should be refreshed. If empty, no cached credentials are refreshed. Specifies UIDs/usernames for which the cached credential should be remoed. If empty, no cached credentials are remoed. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Chapter 6. Tasks aailable from Tioli Desktop 165

182 Manage PDOS Serer State This task allows the administrator to indiidually change the state of the daemons comprising a running Tioli Access Manager for Operating Systems instance. The pdosd, pdosauditd, pdoswdd, pdoslpmd, and pdoslrd daemons can be told to Do Nothing, Start, Stop, or Restart. Do Nothing leaes the daemon s state unchanged. Start starts any daemons not currently running in the Tioli Access Manager for Operating Systems instance. Stop stops the daemon, if it is not already stopped. Restart stops the daemon in the Tioli Access Manager for Operating Systems instance and restarts it. The following window corresponds to the Manage PDOS Serer State task: Figure 16. Manage PDOS Serer State Task Window Use the following steps to perform this task: 1. Set the desired state changes for each daemon. 2. Click Execute and Close to perform the task. 166 IBM Tioli Access Manager for Operating Systems: Administration Guide

183 Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Manage PDOS Serer State l PDOS Tasks a pdosd_state a pdosauditd_state a pdoswdd_state a pdoslpmd a pdoslrd_state wruntask t Manage PDOS Serer State l PDOS Tasks a pdosd_state a pdosauditd_state a pdoswdd_state a pdoslpmd a pdoslrd_state h task_endpoint where: pdosd_state pdosauditd_state pdoswdd_state pdoslpmd_state pdoslrd_state Manage PDOS TCB task_endpoint Indicates the change to make to the state of the pdosd daemon. If not one of Start, Stop, or Restart, the daemon s state will remain unchanged. Indicates the change to make to the state of the pdosauditd daemon. If not one of Start, Stop, or Restart, the daemon s state will remain unchanged. Indicates the change to make to the state of the pdoswdd daemon. If not one of Start, Stop, or Restart, the daemon s state will remain unchanged. Indicates the change to make to the state of the pdoslpmd daemon. If not one of Start, Stop, or Restart, the daemon s state will remain unchanged. Indicates the change to make to the state of the pdoslrd daemon. If not one of Start, Stop, or Restart, the daemon s state will remain unchanged. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to modify or alidate the trust status of objects in the Tioli Access Manager for Operating Systems Trusted Computing Base (TCB). An operation and a comma-separated list of objects on which to apply the operation must be supplied. Valid operations are Trust, Untrust, and Validate. Trust marks the specified objects as trusted. Untrust marks the specified objects as untrusted. Validate checks the signature of the specified objects and if they hae been modified, marks them untrusted. Objects must be specified as absolute paths. A list alue of * indicates all objects in the TCB. The following window corresponds to the Manage PDOS TCB task: Chapter 6. Tasks aailable from Tioli Desktop 167

184 Figure 17. Manage PDOS TCB Task Window Use the following steps to perform this task: 1. Enter a comma-separated list of objects in the TCB on which you wish to modify the trust state. A alue of * can be used to indicate all objects in the TCB. 2. Select an operation to perform. Trust marks the files as trusted. Untrust marks the files as untrusted. Validate checks the signature of the files and if they hae been modified, marks them untrusted. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Manage PDOS TCB l PDOS Tasks a operation a objects wruntask t Manage PDOS TCB l PDOS Tasks a operation a objects h task_endpoint where: operation objects task_endpoint Indicates the operation to apply. It must be one of Trust, Untrust, or Validate. Specifies the objects to which to apply the operation. If this alue is the empty string, no objects are modified. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Purge PDOS Hostname Cache This task allows the administrator to remoe entries from the IP address/hostname translation cache used by Tioli Access Manager for Operating Systems. Two non-exclusie options are aailable remoing all stale entries and remoing entries by name. Entries to be remoed are specified by hostname or IP address in a comma-separated list. If this list contains the special alue *, all entries will be remoed. If the list is empty, no entries will be remoed. 168 IBM Tioli Access Manager for Operating Systems: Administration Guide

185 The following window corresponds to the Purge PDOS Hostname Cache task: Figure 18. Purge PDOS Hostname Cache Task Window Use the following steps to perform this task: 1. Enter a comma-separated list of the IP addresses and/or hostnames that are to be remoed from the cache. The alue * can be used to indicate all cache entries. 2. If cache entries that hae exceeded their expiration date should be remoed, check Remoe all stale entries from database. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Purge PDOS Hostname Cache l PDOS Tasks a remoe_entries a remoe_stale wruntask t Purge PDOS Hostname Cache l PDOS Tasks a remoe_entries a remoe_stale h task_endpoint where: remoe_entries remoe_stale task_endpoint Indicates which entries to remoe from the cache. If this alue is the empty string, no entries will be remoed. Indicates whether stale entries should be remoed. This alue must be either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Query Branch Membership This task can be used to report the machines that are subscribed to a particular Tioli Access Manager for Operating Systems branch. The following window corresponds to the Query Branch Membership task: Chapter 6. Tasks aailable from Tioli Desktop 169

186 Figure 19. Query Branch Membership Task Window Use the following steps to perform this task: 1. Enter the Tioli Access Manager user name. 2. Enter the password for the Tioli Access Manager user. 3. Enter the name of the policy branch whose membership you are trying to determine. 4. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Query Branch Membership l PDOS Tasks a pd_admin_id a pd_admin_passwd a policy_branch wruntask t Query Branch Membership l PDOS Tasks a pd_admin_id a pd_admin_passwd a policy_branch h task_endpoint where: pd_admin_id Specifies the name of a Tioli Access Manager for Operating Systems account that will be used to perform the query. pd_admin_passwd Specifies the password of the user account. policy_branch Specifies which policy branch to report the subscribed machines for. task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name: separate multiple names with spaces. Query PDOS Login and Password Policy This task allows the administrator to generate reports related to Tioli Access Manager for Operating Systems login and password policy. Two types of reports can be generated: 170 IBM Tioli Access Manager for Operating Systems: Administration Guide

187 Reports can be created that show the status of user accounts or that show all details related to a user s record in the Tioli Access Manager for Operating Systems Login Actiity Database. Reports can be created detailing the default login and password policy for all users or the policy for specific users. The following window corresponds to the Query PDOS Login and Password Policy task: Figure 20. Query PDOS Login and Password Policy Task Window Use the following steps to perform this task: 1. If you want to generate a user status report, click Generate user status report and specify the reporting requirements. 2. A comma-separated list of users whose status should be queried can be specified. 3. For login and password information, click Display login and password policy. 4. A comma-separated list of users whose login and password policy should be reported can be specified. 5. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: Chapter 6. Tasks aailable from Tioli Desktop 171

188 wrunjob Query PDOS Login and Password Policy l PDOS Tasks a generate_report a detailed a enabled a disabled a report_users a display_policy a policy_users wruntask t Query PDOS Login and Password Policy l PDOS Tasks a generate_report a detailed a enabled a disabled a report_users a display_policy a policy_users h task_endpoint where: generate_report Indicates whether or not to create a report showing the user entries in the Tioli Access Manager for Operating Systems Login Actiity Database. This alue must be either TRUE or FALSE. detailed Specifies if the user status report should include detailed information on each user entry, or simply its status. This alue must be either TRUE or FALSE. enabled If this parameter is set to TRUE, only unlocked (enabled) user entries will be shown. If this parameter is set to TRUE, disabled cannot also be set to TRUE. disabled Query PDOS Serer State If this parameter is set to TRUE, only locked (disabled) user entries will be shown. If this parameter is set to TRUE, enabled cannot also be set to TRUE. report_users A comma-separated list of users can be specified. Only the user entries from the users in the list will be reported. display_policy Indicates whether or not to create a report showing the Tioli Access Manager for Operating Systems login and password policy. This alue must be either TRUE or FALSE. policy_users A comma-separated list of users can be specified. Only the Tioli Access Manager for Operating Systems login and password policy for the users in the list will be reported. If this parameter is blank, then the default Tioli Access Manager for Operating Systems login and password policy will be reported. task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to indiidually determine the current state of the daemons comprising a running Tioli Access Manager for Operating Systems instance. The following window corresponds to the Query PDOS Serer State task: 172 IBM Tioli Access Manager for Operating Systems: Administration Guide

189 Figure 21. Query PDOS Serer State Task Window Use the following steps to perform this task: 1. Select the daemons on which to report status. 2. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Query PDOS Serer State l PDOS Tasks a query_pdosd a query_pdosauditd a query_pdoswdd a query_pdoslpmd a query_pdoslrd wruntask t Query PDOS Serer State l PDOS Tasks a query_pdosd a query_pdosauditd a query_pdoswdd a query_pdoslpmd a query_pdoslrd h task_endpoint where: query_pdosd Indicates whether the state of the pdosd daemon should be reported. It must be either TRUE or FALSE. query_pdosauditd Indicates whether the state of the pdosauditd daemon should be reported. It must be either TRUE or FALSE. query_pdoswdd query_pdoslpmd query_pdoslrd task_endpoint Indicates whether the state of the pdoswdd daemon should be reported. It must be either TRUE or FALSE. Indicates whether the state of the pdoslpmd daemon should be reported. It must be either TRUE or FALSE. Indicates whether the state of the pdoslrd daemon should be reported. It must be either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Chapter 6. Tasks aailable from Tioli Desktop 173

190 Query PDOS TCB This task allows the administrator to query the trust status of objects in the Tioli Access Manager for Operating Systems Trusted Computing Base (TCB). A comma-separated list of objects on which to report the trust status must be specified. Object names must be proided as absolute paths. Three special list alues can be used: * specifies all objects in the TCB, AnyTrusted specifies all trusted objects in the TCB, and AnyUntrusted specifies all untrusted objects in the TCB. The following window corresponds to the Query PDOS TCB task: Figure 22. Query PDOS TCB Task Window Use the following steps to perform this task: 1. Specify any general categories of file system objects to report using the Report all trusted files / Report all untrusted files options. 2. Optionally, select any specific file system objects to be reported. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Query PDOS TCB l PDOS Tasks a query_objects wruntask t Query PDOS TCB l PDOS Tasks a query_objects h task_endpoint where: query_objects task_endpoint Specifies a list of objects on which to report the trust status. Three special list alues can be used: * specifies all objects in the TCB, AnyTrusted specifies all trusted objects in the TCB, and AnyUntrusted specifies all untrusted objects in the TCB Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. 174 IBM Tioli Access Manager for Operating Systems: Administration Guide

191 Restore PDOS Database This task allows the administrator to restore a specified Tioli Access Manager for Operating Systems backup file. The path to the backup file may be absolute or relatie. If the path is relatie, it is assumed to be relatie to /ar/pdos/pdosbkup. The following window corresponds to the Restore PDOS Database task: Figure 23. Restore PDOS Database Task Window Use the following steps to perform this task: 1. Enter the name of a backup file to restore. The name can be either an absolute or relatie path; if relatie, it is assumed relatie to /usr/pdos/pdosbkup. 2. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Restore PDOS Database l PDOS Tasks a filename wruntask t Restore PDOS Database l PDOS Tasks a filename h task_endpoint where: filename task_endpoint Specifies the name of a backup file to restore. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Set PDOS Serer Audit Leel This task allows the administrator to set the global audit leels of the Tioli Access Manager for Operating Systems instance. The audit leel is specified as a mask with the possible masked eents being permitted accesses, denied accesses, administratie eents, Tioli Access Manager for Operating Systems updates, permitted logins, denied logins, process inocations, and accesses to protected files. Auditing can be made erbose. Tioli Access Manager for Operating Systems may also be placed into warning mode, where accesses normally denied will be granted, but an audit record will be generated indicating the bypass. In addition, a modifier indicating how and when the change occurs must be supplied. Valid modifiers are Permanent, Temporary, Chapter 6. Tasks aailable from Tioli Desktop 175

192 and Deferred. Permanent indicates the change will be effectie immediately and persist across a restart of the instance. Temporary indicates the change will be effectie immediately but will not persist across a restart of the instance. Deferred indicates the change will not take effect until a restart of the instance. Action-based audit can also be set for permitted accesses and denied accesses to filter out the generation of audit records at the global leel. Tioli Access Manager for Operating Systems uses the following actions: C D G K L N R U d l o p r w x Connect Change directory Surrogate Kill program Login Create Rename Update timestamp Delete List directory Change ownership Change permission Read Write Execute The following window corresponds to the Set PDOS Serer Audit Leel task: 176 IBM Tioli Access Manager for Operating Systems: Administration Guide

193 Figure 24. Set PDOS Serer Audit Leel Task Window Use the following steps to perform this task: 1. Select the audit eents that should be enabled. Only eents of the specified types will appear in the audit log. Choose actions to audit for both successful and unsuccessful accesses. If none is selected, the action-based audit at the global leel is left unchanged. 2. Check Run in warning mode if Tioli Access Manager for Operating Systems should not enforce security policy, but only log iolations of the policy. 3. Select how the auditing changes should be applied. Deferred changes will not take effect immediately; they take effect on the next restart of Tioli Access Manager for Operating Systems. Permanent changes take effect immediately and will persist een after restarting Tioli Access Manager for Operating Systems. Temporary changes take effect immediately but will not persist after Tioli Access Manager for Operating Systems is restarted. 4. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: Chapter 6. Tasks aailable from Tioli Desktop 177

194 wrunjob Set PDOS Serer Audit Leel l PDOS Tasks a audit_permit a audit_permit_c a audit_permit_d a audit_permit_g a audit_permit_k a audit_permit_l a audit_permit_n a audit_permit_r a audit_permit_u a audit_permit_d a audit_permit_l a audit_permit_o a audit_permit_p a audit_permit_r a audit_permit_w a audit_permit_x a audit_deny a audit_deny_c a audit_deny_d a audit_deny_g a audit_deny_k a audit_deny_l a audit_deny_n a audit_deny_r a audit_deny_u a audit_deny_d a audit_deny_l a audit_deny_o a audit_deny_p a audit_deny_r a audit_deny_w a audit_deny_x a audit_admin a audit_info a logpermit a logdeny a trace_exec a trace_file a warning_mode a change_type wruntask t Set PDOS Serer Audit Leel l PDOS Tasks a audit_permit a audit_permit_c a audit_permit_d a audit_permit_g a audit_permit_k a audit_permit_l a audit_permit_n a audit_permit_r a audit_permit_u a audit_permit_d a audit_permit_l a audit_permit_o a audit_permit_p a audit_permit_r a audit_permit_w a audit_permit_x a audit_deny a audit_deny_c a audit_deny_d a audit_deny_g a audit_deny_k a audit_deny_l a audit_deny_n a audit_deny_r a audit_deny_u a audit_deny_d a audit_deny_l a audit_deny_o a audit_deny_p a audit_deny_r a audit_deny_w a audit_deny_x a audit_admin a audit_info a logpermit a logdeny a trace_exec a trace_file a warning_mode a change_type h task_endpoint where: audit_permit Indicates that auditing of permitted accesses should be done. This alue must be either TRUE or FALSE. audit_[permit deny] -[C D G K L N R U d l o p r w x] Indicates the selection of action-based audit for permitted or denied access. The alue must be either TRUE or FALSE. audit_deny audit_admin audit_info logpermit logdeny trace_exec trace_file warning_mode change_type task_endpoint Indicates that auditing of denied accesses should be done. This alue must be either TRUE or FALSE. Indicates that auditing of administratie eents should be done. This alue must be either TRUE or FALSE. Indicates that auditing of automatic actions taken within Tioli Access Manager for Operating Systems, such as receiing alid policy updates, should be done. This alue alue must be either TRUE or FALSE. Indicates that auditing of all authorization decisions that permit a login should be done. This alue must be either TRUE or FALSE. Indicates that auditing of all authorization decisions that deny a login should be done. This alue must be either TRUE or FALSE. Indicates that auditing of all process inocations should be done. This alue must be either TRUE or FALSE. Indicates that auditing of all accesses to protected files should be done. This alue must be either TRUE or FALSE. Indicates that Tioli Access Manager for Operating Systems should run in warning mode. This alue must be either TRUE or FALSE. Indicates the type of change. This alue must be one of Permanent, Temporary, or Deferred. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. 178 IBM Tioli Access Manager for Operating Systems: Administration Guide

195 Set PDOS Serer Trace Leel This task allows the administrator to set the current tracing leels of the daemons comprising the Tioli Access Manager for Operating Systems instance and is intended to be used in conjunction with Tioli Customer Support. The entry of random strings for trace leels is not recommended. The following window corresponds to the Set PDOS Serer Trace Leel task: Figure 25. Set PDOS Serer Trace Leel Task Window Use the following steps to perform this task: 1. Enter sericeability trace strings for the desired daemons. 2. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: Chapter 6. Tasks aailable from Tioli Desktop 179

196 wrunjob Set PDOS Serer Trace Leel l PDOS Tasks a pdosd_trace a pdosauditd_trace a pdoswdd_trace a pdoslpmd_trace a pdoslrd_trace wruntask t Set PDOS Serer Trace Leel l PDOS Tasks a pdosd_trace a pdosauditd_trace a pdoswdd_trace a pdoslpmd_trace a pdoslrd_trace h task_endpoint where: pdosd_trace pdosauditd_trace pdoswdd_trace pdoslpmd_trace pdoslrd_trace task_endpoint Setup TEC Eent Serer for PDOS Indicates the change to make to the trace leel of the pdosd daemon. If the empty string is specified, the daemon s trace leel will remain unchanged. Indicates the change to make to the trace leel of the pdosauditd daemon. If the empty string is specified, the daemon s trace leel will remain unchanged. Indicates the change to make to the trace leel of the pdoswdd daemon. If the empty string is specified, the daemon s trace leel will remain unchanged. Indicates the change to make to the trace leel of the pdoslpmd daemon. If the empty string is specified, the daemon s trace leel will remain unchanged. Indicates the change to make to the trace leel of the pdoslrd daemon. If the empty string is specified, the daemon s trace leel will remain unchanged. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. The Setup TEC Eent Serer for PDOS task automatically configures the Tioli Enterprise Console eent serer to recognize Tioli Access Manager for Operating Systems eents. The task and job are aailable only if both Tioli Access Manager for Operating Systems Enterprise Console Integration and Tioli Enterprise Console Serer are installed. For more information about installing the Tioli Enterprise Console logfile adapter on a Tioli Access Manager for Operating Systems endpoint to send Tioli Access Manager for Operating Systems eents, see Chapter 9, Integrating with Tioli Enterprise Console, on page 283. For more information about Tioli Enterprise Console, see the Tioli Enterprise Console User s Guide. By default, this job will run on the Tioli Enterprise Console eent serer (because this task should only be run on the Tioli Enterprise Console eent serer). The following window corresponds to the Setup TEC Eent Serer for PDOS job and task: 180 IBM Tioli Access Manager for Operating Systems: Administration Guide

197 Figure 26. Setup TEC Eent Serer for PDOS Task Window Use the following steps to perform this task: 1. Select one or two Tioli Access Manager for Operating Systems integration targets. The aailable selections are Integrate with Tioli Enterprise Console and Integrate with Tioli Risk Manager. The task will fail if None is selected. 2. Specify whether you want this task to create a new rule base or add information to an existing rule base. If you create a new rule base, you must proide the following additional information: New Rule Base name. Specifies a name for the new rule base. If a rule base already exists with this name, an error will occur. The default rule base name is PDOS. Rule Base to clone. Specifies the name of an existing rule base from which to copy configuration files. The default name is Default. If Integrate with Tioli Risk Manager is selected, the rule base to clone from must be installed and configured by Tioli Risk Manager. For more information, see the Tioli Risk Manager User s Guide. Chapter 6. Tasks aailable from Tioli Desktop 181

198 Path for new Rule Base. Specifies the directory on the Tioli Enterprise Console serer in which the new rule base s configuration files are to be stored. If this path does not exist, it will be created. If you choose to add to an existing rule base, you must specify a name for the existing rule base. The default rule base name is PDOS. If the rule base you specify does not already exist, an error will occur. 3. Select the name of the eent console to configure. Selecting a console from the list causes the Tioli Access Manager for Operating Systems eent group (through which all Tioli Access Manager for Operating Systems related eents are accessible) to be added to the selected console. If you choose None, you will not receie any Tioli Access Manager for Operating Systems eents at any eent console. 4. Click the Set and Close button to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Setup TEC Eent Serer for PDOS l PDOS Tasks a IntegrateTEC -a IntegrateRM a NeworExisting a ExistingRuleBase a NewRuleBase a CloneRuleBase a RuleBasePath a EentConsole wruntask t Setup TEC Eent Serer for PDOS l PDOS Tasks -a IntegrateTEC a IntegrateRM a NeworExisting a ExistingRuleBase a NewRuleBase a CloneRuleBase a RuleBasePath a EentConsole h task_endpoint where: IntegrateTEC IntegrateRM NeworExisting Specifies whether to integrate with Tioli Enterprise Console. Valid alues are on (integrate with Tioli Enterprise Console) and off (do not integrate). Specifies whether to integrate with Tioli Risk Manager. Valid alues are on (integrate with Tioli Risk Manager) and off (do not integrate). Specifies whether to create a new rule base or use an existing rule base. Valid alues are new (create new database) and exist (use an existing database). If you specify new, you must also specify a name for NewRuleBase. If you specify exist, you must also specify a name for ExistingRuleBase. ExistingRuleBase Specifies the name of the rule base in which to add information. If the exist option is specified, you must supply the name of an existing database. The default name is PDOS. NewRuleBase CloneRuleBase RuleBasePath Specifies a name for the new rule base. If a rule base already exists with this name, an error will occur. If the new option is specified, you must supply a name for the new database. Specifies the name of an existing rule base from which to copy configuration files. The default name is Default. Specifies the full path of the directory on the Tioli Enterprise Console serer in which the new rule base s configuration files are to be stored. If this path does not exist, it will be created. 182 IBM Tioli Access Manager for Operating Systems: Administration Guide

199 EentConsole task_endpoint Specifies the name of the eent console to be configured with this rule base. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Notes: 1. If you choose integration with Tioli Risk Manager, and the Tioli Enterprise Console eent serer in your enironment is running on a Microsoft Windows NT system, you must customize the $RMADHOME/etc/riskmgr_baroc.lst file to include the pdosrm.baroc file. Include the pdos.baroc file also if the eent serer should send eents to the Tioli Enterprise Console as well. Make your changes effectie by entering the following commands using the bash shell from the eent serer after running this task: cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdosrm.baroc \ $RMADHOME/etc/baroc/ cp $BINDIR/../generic_unix/TME/PDOSTASKS/pdos.baroc \ $RMADHOME/etc/baroc/ $RMADHOME/bin/rmcorr_cfg -update 2. Tioli Access Manager for Operating Systems Risk Manager eents can be integrated with IBM Tioli Enterprise Data Warehouse. Additional steps are required to ensure that eents are properly integrated in the data warehouse product. Refer to Chapter 10, Integrating with IBM Tioli Risk Manager, on page 287 for more information. Show PDOS Auditing Configuration This task allows you to reiew the parameters related to Tioli Access Manager for Operating Systems auditing. When you run this task from the desktop, the audit parameters are displayed in a window. Displayed output includes the maximum file size of an audit log and how often, in seconds, audit log buffers are flushed to disk. If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Auditing Configuration l PDOS Tasks wruntask t Show PDOS Auditing Configuration l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS Auditors/Administrators This task can be used to display users who hae auditor or administrator priileges. To be an auditor, the user must be a member of both the osseal-auditors Tioli Access Manager group and the ossaudit UNIX group. To be an administrator, the user must be a member of the osseal-admin Tioli Access Manager group and a member of the osseal UNIX group. Chapter 6. Tasks aailable from Tioli Desktop 183

200 The Show Auditors and Show Administrators check boxes are used to select which UNIX and Tioli Access Manager groups to display. To run this task, a Tioli Access Manager administrator s name and password must be specified. The following window corresponds to the Show PDOS Auditors/Administrators task: Figure 27. Show PDOS Auditors/Administrators Task Window Use the following steps to perform this task: 1. You must specify the first two fields. 2. Select the types of Tioli Access Manager for Operating Systems users you want to display. 3. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Auditors/Administrators l PDOS Tasks a pd_admin_id a pd_admin_passwd a show_auditors a show_admins wruntask t Show PDOS Auditors/Administrators l PDOS Tasks a pd_admin_id a pd_admin_passwd a show_auditors a show_admins h task_endpoint where: pd_admin_id Specifies the name of a Tioli Access Manager administratie account that will be used to generate the report. Completion of this parameter is required. pd_admin_passwd Specifies the password of the administratie account. Completion of this parameter is required. show_auditors If this parameter is set to TRUE, the members of the Tioli Access 184 IBM Tioli Access Manager for Operating Systems: Administration Guide

201 Manager osseal-auditors group and the UNIX osseal group are displayed. This alue must be either TRUE or FALSE. show_admins If this parameter is set to TRUE, the members of the Tioli Access Manager osseal-admin group and the UNIX ossadmin group are displayed. This alue must be either TRUE or FALSE. task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS Caching Configuration This task allows you to reiew the parameters related to Tioli Access Manager for Operating Systems internal caches. When you run this task from the desktop, the cache parameters are displayed in a window. Displayed output includes how often (in minutes) to refresh cached administrator credentials, how often (in minutes) to refresh cached user credentials, how long (in minutes) to cache unaccessed user credentials, the critical system users group, how often (in minutes) to refresh critical system user credentials, how long (in minutes) to wait for LDAP responses before going into isolation mode, whether hostname caching is turned on, and whether username caching is turned on. If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Caching Configuration l PDOS Tasks wruntask t Show PDOS Caching Configuration l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS Logging Configuration This task allows you to reiew the parameters related to logging for the Tioli Access Manager for Operating Systems daemons, pdosd, pdoswdd, pdosauditd, and pdoslrd. When you run this task from the desktop, the logging parameters are displayed in a window. Displayed output includes the number of log files and the maximum number of entries in the log files. If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Logging Configuration l PDOS Tasks Chapter 6. Tasks aailable from Tioli Desktop 185

202 wruntask t Show PDOS Logging Configuration l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS Serer Audit Leel This task allows you to reiew the parameters related to the Tioli Access Manager for Operating Systems instance s auditing leel. When you run this task from the desktop, these parameters are displayed in a window. Displayed output includes the current audit leel (permitted accesses, denied accesses, and administratie eents) and whether Tioli Access Manager for Operating Systems is in warning mode, where all accesses are granted but accesses that would normally be denied generate audit records. Also, the configured audit leels are displayed. Configured audit leels will be in effect after the next restart of Tioli Access Manager for Operating Systems. If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Serer Audit Leel l PDOS Tasks wruntask t Show PDOS Serer Audit Leel l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS Serer Configuration This task allows you to reiew miscellaneous parameters for the Tioli Access Manager for Operating Systems serer. When you run this task from the desktop, the parameters are displayed in a window. If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Displayed output includes the following information. the port Tioli Access Manager for Operating Systems uses to receie notifications of policy updates how often, in minutes, to poll for policy updates whether system and password login restrictions are enabled the number of kernel threads used to handle authorization requests whether Tioli Access Manager for Operating Systems is configured to start automatically at system startup the policy branch name whether first failure data capture is enabled whether log router daemon pdoslrd is configured. 186 IBM Tioli Access Manager for Operating Systems: Administration Guide

203 Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS Serer Configuration l PDOS Tasks wruntask t Show PDOS Serer Configuration l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Show PDOS TCB Configuration This task allows you to reiew parameters related to the Tioli Access Manager for Operating Systems Trusted Computing Base (TCB). When you run this task from the desktop, the parameters are displayed in a window. Displayed output includes the number of threads used to monitor TCB objects, the interal (in seconds) between TCB monitoring runs, and the maximum number of bytes in megabytes from a file to use in a checksum (TCB signature). If a parameter s alue is blank, it has neer been explicitly configured and is using its default alue. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Show PDOS TCB Configuration l PDOS Tasks wruntask t Show PDOS TCB Configuration l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Start PDOS TEC Adapter This task allows the administrator to start the Tioli Access Manager for Operating Systems Tioli Enterprise Console daemon and the Tioli Enterprise Console logfile adapter. This task will not start the processes if they are already running. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Start TEC Adapter l PDOS Tasks wruntask t Start TEC Adapter l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or Chapter 6. Tasks aailable from Tioli Desktop 187

204 Stop PDOS TEC Adapter endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. This task allows the administrator to stop the Tioli Access Manager for Operating Systems Tioli Enterprise Console daemon and the Tioli Enterprise Console logfile adapter. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Stop TEC Adapter l PDOS Tasks wruntask t Stop TEC Adapter l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Subscribe PDOS Endpoints This task creates a list of all managed nodes and endpoints that hae had Tioli Access Manager for Operating Systems installed on them. These managed notes and endpoints are then added to the subscriber list of the local PDOS profile manager. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Subscribe PDOS Endpoints l PDOS Tasks wruntask t Subscribe PDOS Endpoints l PDOS Tasks h task_endpoint where: task_endpoint Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Update PDOS Hostname Cache This task allows the administrator to add entries to the IP address/hostname translation cache used by Tioli Access Manager for Operating Systems, as well as to force a refresh of all cache entries. Two non-exclusie options are aailable refreshing all cache entries and adding new cache entries. New entries to add are specified by hostname or IP address in a comma-separated list. If this list is empty, no entries will be added. When adding entries, a time-to-lie may be proided indicating how many seconds the entry will remain alid in the cache. If omitted, a reasonable default is used. 188 IBM Tioli Access Manager for Operating Systems: Administration Guide

205 The following window corresponds to the Update Hostname Cache task: Figure 28. Update Hostname Cache Window Use the following steps to perform this task: 1. Enter a comma-separated list of hostnames/ip addresses to add to the hostname cache. If empty, no new entries are added. 2. Enter the number of seconds that newly added entries remain alid in the Cache timeout field. 3. If all entries currently in the cache should be refreshed, check Refresh all database entries. 4. Click Execute and Close to perform the task. Syntax for wrunjob and wruntask Use the following arguments, in the order shown, to run this task from the command line or a script using wrunjob or wruntask: wrunjob Update Hostname Cache l PDOS Tasks a add_entries a entry_ttl a refresh wruntask t Update Hostname Cache l PDOS Tasks a add_entries a entry_ttl a refresh h task_endpoint where: add_entries entry_ttl refresh task_endpoint Indicates which entries to add to the cache. If this alue is the empty string, no new entries are added. Indicates the length of time (in seconds) any newly added cache entries will remain alid. If this alue is the empty string, a default alue is used. Indicates whether all cache entries should be refreshed. This alue must be either TRUE or FALSE. Specifies the name of the profile manager, managed node, or endpoint on which to run the task. You can specify more than one name; separate multiple names with spaces. Chapter 6. Tasks aailable from Tioli Desktop 189