10    Administering the Audit Subsystem

This chapter describes the purpose of system auditing, how auditing is performed, what activities should be audited, and how to read and respond to audit reports. Responsibilities, managing events, tools, and generating reports are also described.

10.1    Overview of Auditing

In its simplest form, auditing consists of the following:

1. An activity on the system results in the generation of an audit record. This audit record contains information about the activity, such as what the activity was, when it occurred, and the ID of the user who caused it.

   As security manager, you decide which activities will result in the generation of audit records. This choosing of what to audit is sometimes called preselection.

2. The audit record is stored along with other audit records in a file, the audit log.

3. You use a utility to select information from the audit log file and to generate reports from that information. This process is sometimes called post-reduction.

Figure 10-1 provides an overview of the audit subsystem.

Figure 10-1:  The Audit Subsystem

Auditing provides you with a powerful tool for monitoring activity on the system. Through auditing, you can accomplish the following:

• Discourage users from attempting to violate security. A user who knows that system activities are monitored and that security violations can be tracked to the responsible individual might be dissuaded from attempting to violate security.

• Detect attempts at violations or activities indicative of probing a system for weak points. If an audit reveals failed attempts to violate system security, you can take counter measures to lessen the likelihood of later attempts succeeding.

• Assess damage and restore the system if a break-in should occur. Careful analysis of an audit trail after a break-in can help you determine what occurred during the security violation and what steps are needed to return the system to its original state. It also allows you to take steps to prevent similar break-ins in the future.

• Evaluating and debugging application software. The capability of audit to monitor the completion status and arguments of system calls for a designated process provides the ability to assess what is going on inside an application. You can also determine which files the application is attempting to access even if you do not have the source code. Refer to Section 10.13 for more information.

It is important that you inform users of the purpose and, in general terms, the nature of the auditing performed on the system. Present auditing in a positive light, as a tool to help protect the users' files and their access to system resources. This helps minimize any resentment; users who are openly told that their system is regularly audited are less likely to feel as though they are being spied upon. For those users who might be tempted to violate security, knowledge that activities are monitored can be a powerful deterrent.

To manage the audit subsystem, you perform the following tasks:

• Configure the audit system

• Select activities to be audited

• Produce audit reports

• Manage disk space used by the audit subsystem.

• Archive audit files

10.1.1    Audit Files

Table 10-1 describes the files used by the audit subsystem.

Table 10-1:  Files Used for Auditing

The Tru64 UNIX audit subsystem records activities in any file at any location chosen by the system administrator; the default log file is /var/audit/auditlog.hostname.nnn.

10.1.2    Audit Tools

The tools for auditing on Tru64 UNIX systems can be divided into two categories:

• The audit subsystem, which has powerful features unique to the trusted Tru64 UNIX operating system. This is the trusted method for performing security-relevant auditing.

• Traditional UNIX operating system logging features, such as the system accounting files and the last command.

The audit subsystem provides a choice of the events to be logged, flexible data reduction of the audit log, and ease of maintenance. These features can be accessed through either a powerful command-line interface or through an easy-to-use graphic interface that provides point-and-click operation and on-line help.

10.1.2.1    Command-Line Interface

The following commands are used with the audit subsystem:

sysman auditconfig

Establishes the audit environment on your system.

auditmask

Selects events for inclusion in the audit log or displays a list of events currently being recorded in the audit log.

audgen

Provides the ability, from the command line, to generate a log record containing a message of your choice.

auditd

Activates the auditing daemon (turns on auditing), administers audit data storage, and configures the audit subsystem.

audit_tool

Selectively extracts information from the audit log and presents it in a readable form.

audit_tool.ultrix

Selectively extracts information from an audit log created on an ULTRIX system and presents it in a readable form.

Use of these commands is limited to those with superuser status.

10.1.2.2    Graphical Interface

The graphical interface to the audit subsystem is accessed using the CDE Dashboard as follows:

System Applications-->Daily Administration-->Audit Manager

Configuration of the audit subsystem is done with the sysman auditconfig command. All other activities can be handled with the graphical interface. If you intend to use the graphical interface rather than the command-line interface, you will want to read Section 10.4.1 for an overview of the auditd command, but you can skip the other command-line information in Section 10.4.

Use of the graphic interface is limited to those with superuser status.

10.2    Basic Audit Configuration

Use the procedures in this section if you want a simple, default audit configuration.

The audit subsystem configuration is done in two parts. The first part configures the kernel for auditing and establishes audit log management parameters. You select the location for the audit logs, the action that audit takes if file space is exhausted, and for how long the audit logs are held (forever if specified) on your system before being deleted to free disk space. In the second part, you select the events you want to audit.

Note

Auditing must be built into your kernel. In addition to system wide auditing, you may specify auditing of events on a user-by-user basis by including enhanced security subset OSFC2SEC510. The dxaudit graphical interface for audit requires the software subset OSFXC2SEC510.

You can check to see if these subsets have been installed as follows:

# setld -i | grep "C2SEC5.."
OSFC2SEC510    installed    Enhanced Security (System Administration)
OSFXC2SEC510   installed    Enhanced Security GUI (System Administration)
 

If the subsets do not show as installed, refer the setld(8) reference page for information on how to install these subsets.

The following steps show you how to quickly get the audit subsystem up and running in a simple, default configuration. The screen names that are referenced are found in the title bar of each screen:

1. Begin by executing the sysman auditconfig command to start configuring audit. Note that if the audit subsystem is not configured into your system's kernel, sysman auditconfig guides you through a kernel rebuild.

   1. Click Yes on the Welcome screen to begin configuring audit.

   2. Click OK on the Information screen.

   3. Accept the default for the audit log location (/var/audit/auditlog.hostname.nnn) by clicking Next on the Log Pathname screen.

   4. Accept the default for the action if log space is exhausted (Suspend auditing until space becomes available) by clicking Next on the Action On Log File Space Exhaustion screen.

   5. Accept the default for the audit log lifespan in months (forever), and the hour of deletion (3) on the Log File Lifespan screen.

   6. Accept the default for audit console message destination (syslog -- /var/adm/syslog.dated/current/daemon.log) by clicking Finish Part One on the Advanced Audit Options screen.

   7. Proceed to part two by clicking Yes to the question Do you wish to proceed to part two? on the Audit Event Information screen.

2. In part two of configuring audit, you choose your auditing profile or category. Profiles and categories are capitalized in the menu list; there are currently six to choose from:

   Profile/Category	Description
   Desktop	Suggested minimal auditing for a single user system.
   NIS_server	Suggested auditing for a system used as a NIS server.
   Networked_system	Suggested auditing for a system on a network.
   Server	Suggested auditing for a system that is used as a server for networked based applications.
   Timesharing	Suggested minimal auditing for a system that is used to support multiple interactive users.
   Timesharing_extended_audit	Extended auditing for a system that is used to support multiple interactive users.

   1. Select the profile or category closest to the configuration of your system and click Next on the Audit Event Category Selection screen.

      Note that use of the CTRL key allows the selection of more than one category, for example Desktop and Networked_system for a desktop system on a network. While multiple selections are possible, use the minimum profile that meets your needs.

      Accept the default list of events to be audited by clicking Next on the Advanced User Audit Event Modification/Deletion screen.

   2. Some profiles and categories include this step, otherwise skip to the next step. Accept the default list of files to be audited by clicking Next on the UNIX File System Objects screen. Note that this menu item does not appear for all profiles and categories.

   3. Accept the options for audit events that have been set as a result of the profile or category that were selected by clicking Finish on the Advanced Options screen.

3. Complete the audit set up by clicking OK on the Audit Configuration Complete screen.

4. Check the configuration of the audit subsystem by entering the auditd -w command. If you took the system default, your configuration looks like the following:

   # auditd -w
    
   Audit data and msgs:
   -l) audit data destination                 = /var/audit/auditlog.hostname.001  [1]
   -c) audit console messages                 = syslog  [2]
    
   Network:
   -s) network audit server status (toggle)   = off  [3]
   -t) connection timeout value (sec)         = 4
    
   Overflow control:
   -f) % free space before overflow condition = 10  [4]
   -o) action to take on overflow             = suspend audit  [5]
    
   

   1. The name of the audit log. [Return to example]

   2. The location of audit subsystem messages. Changes in the status of the audit subsystem are recorded here. [Return to example]

   3. Auditing across the network is not enabled (remote clients may not log to this system). [Return to example]

   4. Percent of remaining free space in the file system that will trigger an audit overflow condition. In this case, 10 percent.

      If the file system containing the audit log becomes 90 percentfull, the audit subsystem takes an overflow action. [Return to example]

   5. The overflow action is to suspend auditing until storage space is available.

      In place of alternate file systems, any directory names specified in /etc/sec/auditd_loc are displayed. [Return to example]

10.3    Advanced Configuration of Audit

This section provides audit procedures to establish a customized audit configuration. Advanced users will find pointers to more detailed information about the configuration questions. The responses supplied in this section are suggestions; once you become familiar with the audit configuration process, you may want to select different responses.

Note

The auditmask features that allow you to specify auditing of events on a user-by-user basis require the enhanced security subset OSFC2SEC510. The dxaudit graphical interface for audit, requires the software subset OSFXC2SEC510.

You can check to see if these subsets have been installed as follows:

# setld -i | grep "C2SEC5.."
OSFC2SEC510    installed    Enhanced Security (System Administration)
OSFXC2SEC510   installed    Enhanced Security GUI (System Administration)
 

If the subsets do not show as installed, refer the setld(8) reference page for information on how to install these subsets.

The audit subsystem configuration is done in two parts. The first part configures the audit logs your system creates. You select the location for the audit logs, the action that audit takes if file space is exhausted, and how long the audit logs are held (forever if specified) on your system before being deleted to free disk space. In the second part, you select the events you want to audit.

The following steps show you how to get the audit subsystem up and runing in a custom configuration for your site. The screen names that are referenced are found in the title bar of each screen:

1. In part one of the configuring audit, you execute the sysman auditconfig command to start configuring audit.

   1. Click on Yes on the Welcome screen to begin configuring audit.

   2. Click on OK on the Information screen.

   3. Select the audit log location (/var/audit/auditlog.hostname.nnn) by selecting Next on the Log Pathname screen.

   4. Accept the default for the action if log space is exhausted (Suspend auditing until space becomes available) by selecting Next on the Action On Log File Space Exhaustion screen. Refer to -o option in the auditd(8) reference page for more information.

   5. Select the audit log lifespan in months (forever), and the hour of deletion (3) on the Log File Lifespan screen. Refer to Section 10.6.2.1.

   6. Select the audit console message destination (syslog -- /var/adm/syslog.dated/current/daemon.log) by selecting Finish Part One on the Advanced Audit Options screen. Refer to Section 10.7.

   7. Proceed to part two by selecting Yes to the question Do you wish to proceed to part two? on the Audit Event Information screen.

2. In part two of configuring audit, you need to pick from a list of six profiles or categories. The profiles set up audit style (/etc/rc.config.common AUDITMASK_FLAG), audit events (/etc/sec/rc_audit_ events), and files to be audited (/etc/sec/fs_objects), which are used to set up the audit subsystem at system startup. The first letter of the profiles are capitalized in the menu list; there are currently six to choose from:

   Profile/Category	Description
   Desktop	Suggested minimal auditing for a single user system.
   NIS_server	Suggested auditing for a system used as a NIS server.
   Networked_system	Suggested auditing for a system on a network.
   Server	Suggested auditing for a system that is used as a server for network based applications.
   Timesharing	Suggested minimal auditing for a system that is used to support multiple interactive users.
   Timesharing_extended_audit	Extended auditing for a system that is used to support multiple interactive users.

   1. Select the profile or category closest to the configuration of your system and click Next on the Audit Event Category Selection screen. Refer to Section 10.6.1.4.

      Select the default list of events to be audited by clicking on Next on the Advanced User Audit Event Modification/Deletion screen. Refer to Section 10.6.1.

   2. Select the default list of files for auditing by clicking on Next on the UNIX File System Objects screen. Note that this menu item does not appear for all profiles and categories. Refer to Section 10.6.1.3.

   3. Select the options for audit events that have been set as a result of the profile or category that was selected by clicking Finish on the Advanced Options screen. Refer to Section 10.6.1 and the -s option in the auditmask(8) reference page.

3. Complete the auditing setup by clicking OK on the Audit Configuration Complete screen. Audit is now running.

4. Check the configuration of the audit subsystem by entering the auditd -w command. If you took the system default, your configuration looks like the following:

   # auditd -w
    
   Audit data and msgs:
   -l) audit data destination                 = /var/audit/auditlog.hostname.001  [1]
   -c) audit console messages                 = syslog  [2]
    
   Network:
   -s) network audit server status (toggle)   = off  [3]
   -t) connection timeout value (sec)         = 4
    
   Overflow control:
   -f) % free space before overflow condition = 10  [4]
   -o) action to take on overflow             = suspend audit  [5]
    
   

   1. The name of the audit log. [Return to example]

   2. The location of audit subsystem messages. Changes in the status of the audit subsystem are recorded here. [Return to example]

   3. Auditing across the network is not enabled (remote clients may not log to this system). [Return to example]

   4. Percent of remaining free space in the file system that will trigger an audit overflow condition. In this case, 10%.

      If the file system containing the audit log becomes 90% full, the audit subsystem takes an overflow action. [Return to example]

   5. The overflow action is to suspend auditing until storage space is available. [Return to example]

10.4    Audit Commands

The auditd, auditmask and audit_tool commands are described in this section. The auditd and auditmask commands control the audit subsystem. The audit_tool command generates reports from the output of the audit subsystem.

Changes made to the audit subsystem with auditd and auditmask commands are temporary and are reset on a system reboot.

The current system defaults for the audit subsystem are stored in the /etc/rc.config.common file.

AUDITMASK_FLAG is used to pass command line arguments to auditmask at system startup. AUDITMASK_FLAG sets the audit style flags and sets auditmask to read events selected for auditing from /etc/sec/rc_audit_events. The /etc/sec/fs_objects file contains a list of files that have modified property lists (modified during audit subsystem configuration) that allow the files to be monitored on object selection/deselection. Refer to the auditmask(8) reference page for more information on object selection/deselection.

10.4.1    Configuring the Audit Subsystem: the auditd Command

The auditd command turns on and off the audit daemon and is used to configure the audit daemon. Table 10-2 gives examples of uses of the auditd command. For a complete description, see the reference page for auditd(8).

Table 10-2:  auditd Examples

10.4.2    Selecting Events to Audit: The auditmask Command

The auditmask command sets the system and process audit masks, which determine what gets audited on the system. The following table gives examples of uses of the auditmask command. For a complete description, see the reference page for auditmask(8).

10.4.3    Producing Audit Reports: The audit_tool Command

Figure 10-2 illustrates how audit_tool converts binary data to an ASCII report. The table that follows gives examples of how to use the audit_tool command. For a complete description, see the reference page for audit_tool(8).

Figure 10-2:  Audit Report Formats

Generating Audit Reports

10.5    What to Audit

There are three categories of auditable events on a Tru64 UNIX system:

• System calls (including Mach events)

• Trusted events

• Site-defined events

All system calls and trusted events of possible security relevance are listed in the file /etc/sec/audit_events .

To generate a list of all possible auditable events, including site-defined events, and save it in the file all_auditable_events, enter the following commands:

# auditmask > original_audit_mask   [1]
# auditmask -f   [2] 
# auditmask > all_auditable_events   [3]
# auditmask -n   [4]
# auditmask < original_audit_mask   [5]

Note

The auditmask -f command may slow down your system.

1. Save the current audit mask to the file original_audit_mask. [Return to example]

2. Set the audit mask to all events. [Return to example]

3. Save the audit mask to the file all_auditable_events. [Return to example]

4. Set the audit mask to no events. [Return to example]

5. Restore the audit mask to the original events. [Return to example]

A trusted event is an event that is associated with a security protection mechanism; it does not always correspond directly to a system call. A list of the trusted events follows:

audit_daemon_exit

Indicates that the audit daemon exited abnormally. This occurs only when there is insufficient memory available during initialization of the audit daemon. The exit is recorded in the new audit log, and a message is displayed on the designated audit console.

audit_log_change

Indicates that the audit daemon closed the current audit log and began writing a new log (for example, in response to the auditd -x command). The change in logs is recorded in the current audit log, and a message is displayed on the designated audit console.

audit_log_create

Indicates that a new audit log was created in response to the removal of the current log file. The new file has the generation number of the lost log file incremented by 1. The creation of the new log is recorded at the beginning of the new audit log, and a message is displayed on the designated audit console.

audit_log_overwrite

Indicates that the audit daemon began overwriting the current audit log as you specified with the -o overwrite option to auditd. The overwrite is recorded at the beginning of the newly overwritten audit log, and a message is displayed on the designated audit console.

audit_reboot

Indicates that the audit daemon initiated a system reboot (as a result of an overflow of the log) as you specified with the -o halt option to auditd. The reboot is recorded at the end of the current audit log, and a message is displayed on the designated audit console before the reboot occurs.

auditconfig

Indicates that the -o changeloc option to the auditd command was used to change the specified overflow action. The change in the audit setup is recorded in the current audit log.

audit_start

Indicates that the audit daemon has been started.

audit_stop

Indicates that the audit daemon was killed normally (typically, with the -k option to auditd). The shutdown is recorded at the end of the current audit log, and a message is displayed on the designated audit console when the shutdown occurs.

audit_suspend

Indicates that the audit daemon suspended auditing (as a result of an overflow of the log) as you specified with the -o suspend option to auditd. The suspension is recorded in the current audit log, and a message is displayed on the designated audit console.

audit_xmit_fail

Indicates that the audit daemon was sending audit records across a network and the transmission failed. The failure is recorded in the local log specified as the next path in /etc/sec/auditd_loc (with auditd -r) or the default local path (/var/adm).

audgen8

The audgen command (a command-line interface to the audgen() routine) was used to generate an audit record.

auth_event

An event associated with user-authentication and the management of user accounts occurred. Trusted auth_events include passwd, su, rsh, and login. The event is recorded in the current audit log.

login

A user attempted to log-in to the system.

logout

A user logged out of the system.

10.5.2    Site-Defined Audit Events

A site can define its own audit events (referred to as site-defined events). This is useful if you want applications to generate records specific to their activities.

Trusted application software can generate data for the site-defined events and subevents. The data can be included in the audit logs with the system's audit data or stored in application-specific logs.

Both preselection and postreduction capabilities are supported for site events. That is, you can use the auditmask and audit_tool commands on site-defined events exactly as you do for other audit events. Postreduction capabilities are also supported for subevents.

The system administrator must create an /etc/sec/site_events file, which contains the event names and event numbers for the system's site events. The site_events file has one entry for each site-event. Each site-event entry may contain any number of subevents.

The lowest allowed site event number is MIN_SITE_EVENT, which is defined in <sys/audit.h>. Typically, the number is 2048. By default, up to 64 site-events can be defined. However, this upper limit can be increased up to a maximum 1,048,576.

To change the upper-limit for the allowed number of site events, add an entry in the /etc/sysconfigtab file. For example, to allow up to 5000 site-defined events, use the sysconfigdb command to add the following lines to /etc/sysconfigtab:

 sec:
     audit-site-events=5000

Then reboot the system.

Once /etc/sec/site_events has been set up, applications can use the audgenl() library routine to generate application-specific audit data.

Programming information about providing application-specific auditing is found in the reference page for audgenl(3).

10.5.3    Dependencies Among Audit Events

Some information in the audit log is based on previously audited events. For example, the LOGIN event associates a login name with a real UID (RUID). Subsequent occurrences of that RUID (for a given process) can then be associated with a login name. Such data is called state-dependent information. The following three audit records illustrate state-dependent information. The first record shows a successful open() of /etc/passwd, returning a value of 3:

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
procname:    state_data_test
event:       open
char param:  /etc/passwd
flags:       2 : rdwr
vnode id:    2323       vnode dev:   (8,1024)   [regular file]
object mode: 0644
result:      3 (0x3)
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Wed Nov 10 17:49:59.93 1993

The following record shows the result of an ftruncate() system call for the /etc/passwd file with state-dependent information. The state-dependent data currently associates the file name /etc/passwd with descriptor 3 for this process:

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
procname:    state_data_test
event:       ftruncate
vnode id:    2323      vnode dev:   (8,1024)   [regular file]
object mode: 0644
descriptor:  /etc/passwd (3)
result:      0
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Wed Nov 10 17:49:59.96 1993

If state-dependent data is not being maintained, you would see only that the ftruncate() system call was against descriptor 3 (vnode ID = 2323, dev = 8,1024):

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
event:       ftruncate
vnode id:    2323      vnode dev:   (8,1024)   [regular file]
object mode: 0644
descriptor:  3
result:      0
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Wed Nov 10 17:49:59.96 1993

Table 10-3 lists state-dependent information and the audit events required to maintain it.

Table 10-3:  State-Dependent Information

The exit() system call informs audit_tool that it no longer needs the state-dependent information for the exiting process. This allows audit_tool to run faster.

If you are not interested in state-dependent data, you do not need to audit exit(), and use the -F option to the audit_tool program for fast mode.

See the audit_tool(8) reference page for more information.

10.6    Managing the Volume of Audit Data

The audit subsystem is capable of generating and collecting large amounts of data. Therefore, it is important for the system administrator to place reasonable limits on the data being generated by the audit subsystem, and to monitor the growth of the audit log data stored on system. This monitoring is needed to make sure that audit logs stored online do not grow to fill the file system and cause a denial of service situation.

10.6.1    Before the Audit Data Is Collected

The audit subsystem provides the following features that allow the system administrator to preselect events for auditing and to easily change those preselections:

• Audit masks and control flags

• Event aliases

• Object selection and object deselection

10.6.1.1    Audit Masks and Control Flags

Audit masks determine which events are audited. There are two kinds of audit masks:

system audit mask

Applies to all processes on the system.

process audit mask

Applies to a specific process.

A special case of the process mask is the login process mask. The login process mask for a user is stored in the password database (/tcb/files/auth.db) in the u_auditmask field.

When the auditmask is set for a user login process, at user login, that audit mask is applied to the login process, and all offspring processes inherit that auditmask.

The per-user auditmask feature, which allows you to specify auditing of events on a user-by-user basis, requires that enhanced security be configured and active.

Audit Control Flag

The audit control flag mediates the interaction between the system audit mask and the process audit mask. Figure 10-3 illustrates how the system and process masks interact.

Figure 10-3:  System and Process Audit Mask Interaction

The audit control flag regulating system mask and process mask interaction can be set from the dxaudit program found on the CDE Dashboard, as follows:

Application Manager-->Daily Administration-->Audit Manager--> Collection--> Modify Active Process Mask

From the command line, set the system mask and process mask interaction using the auditmask -c command as follows:

User Process Control Flag

In the case of a user's login-process mask, the u_auditcntl field in the user's entry in the enhanced (protected) password database stores the value for the control flag.

The control flag for a user's login process is set with the dxaccounts program found on the CDE Dashboard, as follows:

Application Manager-->Daily Administration-->Account Manager-->Security Attributes-->Login Process Mask

10.6.1.2    Event Aliases

An event alias groups multiple audit events events under a single name. You define an event alias in the file named /etc/sec/event_aliases. The file consists of a series of alias definitions. Each definition has the following format:

[alias: event[:success:failure] [event[:success:failure]...]]

An event can be a system call, trusted event, site event, or another alias. The success and fail notation is the same one used for auditmask and audit_tool. Continuation lines are allowed.

A few carefully defined event aliases can provide a wide range of auditing coverage, allowing you to easily change auditing preselection.

Event aliases are selected for auditing just as any other event -- with the auditmask command or the Audit Manager graphical interface.

See /etc/sec/event_aliases for an example of an alias file. The Tru64 UNIXTru64 UNIX event aliases and profiles are defined in this file. Compaq reccommends that you add your own aliases to the end of the /etc/sec/event_aliases file.

10.6.1.3    Object Selection and Deselection

The object selection and deselection modes provide another preselection mechanism designed to help administrators audit specifically those operations of interest to them. The file object selection and deselection mechanism provides a further level of granularity for events which operate on files.

Events such as mount and reboot affect system state. Data access events, such as open and stat, act on files. Although reboot attempts might always be security relevant, not all file open events are (depending on the site security model).

Object selection and deselection let you chose which files do (selection) or do not (deselection) result in audit records when those files are objects of data access operations.

The data access operations that can be selected or deselected are:

read       open               close
link       lseek              access
stat       lstat              dup
open       revoke             readlink
fstat      pre_F64_stat       pre_F64_lstat
dup2       pre_F64_fstat      readv
pread      getdirentries      stat
lstat      fstat              _F64_readv

Object selection and deselection work as follows:

Selection

The object selection mode provides the ability to specify a set of files for which selected events are audited, while those same events on other files are not audited. In the selection mode, audit records are generated only when an event is selected and either that event is acting on a selected file or not acting on any file.

For example, you can flag the /etc/passwd and /.rhosts files, enable object selection, and audit the open system call. This causes an open on /etc/passwd and /.rhosts to be audited while an open on /tmp/xxxx files is not audited.

Deselection

The file deselection mode provides the ability to specify a set of files for which specific selected events are not audited, while those same events on other files are audited. The events that may be deselected are data access operations (no data modifications). File open's for write or truncate access are examples of file modification.

In the deselection mode, audit records are generated for selected events, unless all files operated on by the system call are deselected and the operation is a data access. So, if you are auditing stat and unlink, and the file foo is deselected, then a stat of foo would not be audited, but an unlink of foo would be audited (the unlink is not a data access operation). The result is that it is now possible, for example, to not audit accesses to the /usr/shlib/libc.so library, but still audit open's of the /etc/passwd file.

Audit selection and deselection do not reduce the auditing of processes for which auditmask -c usr was specified (the value of the audit control flag is AUDIT_USR).

Using object selection and deselection requires the following three steps:

1. Decide which file or files you want to apply object selection or deselection to. If you want to apply selection or deselection to more than one file, you can create a file that is a list of file names (complete path names), one file name per line.

2. Set the audit style either to Object Selection or Object Deselection as appropriate:

   From Audit Manager: Collection-->Audit Style

   From the command line: auditmask -s obj_sel or auditmask -s obj_desel

3. Activate object selection and deselection as follows:

   Object selection for one file:

   # auditmask -x filename

   Object selection for a series of files listed in a file named filelist:

   # auditmask -X filelist

   Object deselection for one file:

   # auditmask -y filename

   Object deselection for a series of files listed in a file named filelist:

   # auditmask -Y filelist

The following are examples of how to enable the selection of a file for audit:

# auditmask -s obj_sel
# auditmask -q /etc/passwd
selection: off     deselection: off  --  /etc/passwd
# auditmask -x /etc/passwd
selection: off => on   --  /etc/passwd
# auditmask -q /etc/passwd
selection: on     deselection: off  --  /etc/passwd
 
 

The following example shows how to disable the selection of a file for audit:

#  auditmask -x /etc/passwd:0

The following example shows how to deselect a list of files:

# auditmask -s obj_desel
# cat desel_file
/etc/motd
/etc/fstab
/etc/passwd
# auditmask -Q desel_file
selection: off    deselection: off  --  /etc/motd
selection: off    deselection: off  --  /etc/fstab
selection: off    deselection: off  --  /etc/passwd
# auditmask -Y desel_file
deselection: off => on   --  /etc/motd
deselection: off => on   --  /etc/fstab
deselection: off => on   --  /etc/passwd
 
 

The status of the object selection and deselection flags for a file list can be displayed from the CDE dashboard as follows:

1. Select Application Manager-->Daily Administration-->Audit Manager-->Modify System Mask-->Current-->Edit -->Object Selection/Deselection.

2. Under File, select /etc/sec/fs_objects.

3. Under File, select List of Files.

4. Settings are not applicable.

5. Click on Query.

Although the system object selection and object deselection audit styles are mutually exclusive, it is possible for any one object to be subject to both models simultaneously on different systems (across NFS). The proplistd daemon needs to be running to transfer attributes across NFS.

10.6.1.4    Audit Profiles and Categories

Audit profile and categories provide a method to consolidate the parameters that define what is monitored by the audit subsystem and group that information under a profile. For this section the terms profile and categories are considered synonymous. Profiles are made up of of three parts:

Audit style information

Located in /etc/sec/auditmask_style under the Profile: label. Refer to the reference page auditmask(8) under the -c option for a descriptions of the valid audit style characteristics.

Audit events to be monitored

Located in /etc/sec/event_aliases under the Profile: label.

Files to be monitored

The list of files is in the /etc/sec/file_objects/Profile file. Monitoring is performed by setting the appropriate object selection and deselection flags. Information in /etc/sec/auditmask_style determines which flags are set. This file is optional and does not need to exist if the audit style defined in /etc/sec/auditmask_style does not include obj_sel or obj_desel.

The following profiles are defined:

Note

You should audit the logout() event. This makes the audit_tool program run faster when reducing audit data.

During phase two of the audit configuration, the auditconfig utility takes the information from the user-specified Profile, modifications to the audit style information, and the events to be audited list (the files to monitor list cannot be changed by the auditconfig). When you have completed the selections, the auditconfig does the following:

• Modifies AUDITMASK_FLAG in /etc/rc.config.common

• Writes the /etc/sec/rc_audit_events file

• Writes the /etc/sec/fs_objects file

10.6.1.5    Audit Subsystem Startup Defaults

The system startup defaults for the audit subsystem are stored in AUDITMASK_FLAG in the /etc/rc.config.common file. This field is used to pass command line arguments to auditmask at system startup. AUDITMASK_FLAG sets the audit style flags and sets auditmask to read the events selected for auditing from the /etc/sec/rc_audit_events file. The /etc/sec/fs_objects file contains a list of the files that have property lists that were modified during the audit subsystem configuration to allow the file to be monitored with object selection and deselection. Refer to the auditmask() reference page for more information on object selection and deselection.

/etc/rc.config.common AUDITMASK_FLAG

Can be modified with rcmgr, sysman auditconfig or with the Audit Manager through the CDE Dashboard.

/etc/sec/rc_audit_events

Can be modified using a text editor, sysman auditconfig, or with the Audit Manager through the CDE Dashboard.

/etc/sec/fs_objects

Modification of /etc/sec/fs_objects requires care. This file contains the only easily available list of files that have the object selection and deselection flags set in the file's property list. Any files that the system administrator needs to set the object selection and deselection flag on, should be included in this file. The /etc/sec/fs_objects file can be modified by using system auditconfig.

The procedure for manually modifying this file is as follows:

Caution

While this procedure is being performed, your system may be vulnerable.

1. Execute the following commands to reset the object selection and deselection flags in the property list:

   
   # auditmask -X /etc/sec/fs_objects:0
   # auditmask -Y /etc/sec/fs_objects:0
   

2. Modify the /etc/sec/fs_objects file using a text editor.

3. If obj_sel is in AUDITMASK_FLAG, use:

   # auditmask -X /etc/sec/fs_objects:1
   

   If obj_desel is in AUDITMASK_FLAG, use:

   
   # auditmask -Y /etc/sec/fs_objects:1
   

10.6.2    After the Data Has Been Collected

After the audit log data has been collected, it is important to have a structured archival procedure for the audit log files. Many of the applications that use the audit log data need to locate and analyze data that can be several months old.

10.6.2.1    Audit Log Trim Procedures

The sysman auditconfig utility provides a method for periodically deleting the binary audit logs using a root cron job. This feature is disabled by default. If enabled, the system administrator should provide for periodic audit log file backup before each cron job run.

The "Audit log lifespan in months" dialog box reflects both the monthly cycle on which the deletion will execute and the criteria for the deletion. The deletion always occurs on the first of the month; the hour is adjustable, but the minute is hardwired to zero. A binary audit log is deleted when all the audit events it contains are older than the deletion execution date minus the "Audit log life span in months".

For example, to create a cron job that runs on the second, fourth, and sixth months on the first day of the month at 3:00AM, enter the following:

"Audit log lifespan in months" = "every second month"
"Hour of deletion(0-23)" = "3"

Binary log files that contain entries that are all at least two months old are deleted at cron execution.

10.7    Auditing Across a Network

If you have computers linked in a TCP/IP network, you can run the audit daemon on multiple systems and feed the information logged to a single system (the audit hub) for storage and analysis, as follows:

1. On the host that is to be the central collecting point for audit information (the audit hub), create the file /etc/sec/auditd_clients. Each line in this file must have the name of a remote host that will be feeding audit data to the local audit daemon.

2. On the audit hub, enter the following command to enable the audit hub to receive audit data from audit daemons on remote hosts specified in the /etc/sec/auditd_clients file:

   
   # /usr/sbin/auditd -s
   

3. On each remote host, direct the audit data to the system that is the audit hub with the following command:

   
   # /usr/sbin/auditd -l audit_hub_name:
   

   If communication is broken with the audit hub and it can no longer receive data, the local daemon stores the audit data locally, as specified with the -o and -r flags to auditd.

4. On the audit hub, you can set options for remote audit daemons as follows:

   auditd [-p ID_of_daemon_serving_remote_host options_for_remote_daemon]

   For example, to set the audit log location to /var/audit/NYC_Sys1 for the remote host served by the audit daemon with ID 6:

   # /usr/sbin/auditd -p 6 -l /var/audit/NYC_Sys1
   

   The ID's of audit daemons serving remote hosts are integers. To learn the ID's, use the command:

   # /usr/sbin/auditd -w
    
    
   

When feeding audit data from remote hosts to an audit hub, direct the audit data from each remote host into its own, dedicated audit log file on the hub system. This is necessary to prevent corruption of audit data, and is done by default.

When you use the audit tool to retrieve data from these logs of audit data from remote systems, the first and last audit log entries may be fragments rather than complete entries. This can happen if the communications channel is not cleanly terminated or if the auditd remotely receiving the data is forced to switch log files. This is because remote audit information is fed in a continuous stream to the audit hub, rather than as discrete audit entries.

The audit tool notifies you when it encounters a fragmented entry. This does not affect the retrieval of other records from the audit log.

10.8    Contents of Audit Records

All audit records, whether originating from system calls, trusted events, site-defined events, or the audgen command include, at a minimum, the following elements. The only exception is that if a login is not completed, audit_id: does not appear.

audit_id:                  ruid/euid:
pid:                       ppid:                cttydev:
event: 
result: 
ip address: 
timestamp:

audit_id:

The Audit ID (AUID). The AUID is associated with a user at login and should remain unchanged throughout the login session. Processes started by the user will have the AUID associated with them. The AUID is not affected by use of the su command to change user IDs.

AUID and LUID (login UID) are synonyms.

Note that a malicious process that gains root access can use setluid() to change its audit ID. To monitor such a privileged process, enable monitoring of the security system calls. A setluid() call is identified in the audit record for the security() by the first argument being 0x3. Both the original and new audit IDs are available from the audit record. The original audit ID is saved as the result code (return value) and the new audit ID is the argument.

ruid/euid:

The real user ID (RUID) and the effective user ID (EUID).

pid:

The process ID.

ppid:

The parent process ID (PPID). Useful for tracing back through a list of processes to the originating event and its associated RUID and AUID.

cttydev:

The device on which the event occurred. The record reports the major and minor numbers.

event:

The name of the event (typically, either the name of a system call or the name of a trusted event).

result: or error:

If the event succeeds, the result. Often the result is 0. But some system calls return a different value. For example write( ) returns the number of bytes written.

In the case of an error, the audit record for a system call returns the error message and number. For example,

error:     Not owner (1)
 

Audit records for trusted events can have additional error messages.

ip address:

The IP address of the system on which event occurred.

timestamp:

The date and time of the event.

10.8.1    Additional Entries in Audit Records

Most entries in an audit record for a system call are arguments to that system call. The following list presents many of the labels for entries that can go into an audit record, and brief explanations of what those labels can mean. But the labels are context-sensitive. That is, their meaning can depend on the type of audit record in which they appear.

For example, in the audit record for mmap( ), flag: indicates an attribute of the mapped region. But in an audit record for audcntl( ), flag: is a number passed with a HABITAT request.

Commands entered on the command line by users appear as arguments to char param: in audit reports. For example, if a user copies the file august_report to a file named sept_report, the audit record includes the following:

event:  execve
char param:  /usr/bin/cp
char param:  cp august_report sept_report

In the context of a given audit record, interpreting the entries is a straightforward matter. If questions do arise, the reference page for the system call being audited will help clarify the report.

The following is a list of the audit record fields and the associated explanations of the fields:

address:

Memory address, typically an argument to mmap( ).

char param:

A character string. The string can be the argument to an event or some other information relevant to the event. For example:

event:       open
char param:  /etc/zoneinfo/localtime

cntl flag:

A control flag. For example, one of the flags to an audcntl( ) request.

descriptor:

A file descriptor. If state-dependent information is available, the actual file name and the descriptor.

devname:

A device name.

directory:

The name of the current directory.

flag:

A flag argument to a system call. For example, in the context of mmap( ), it specifies the attributes of the mapped region. In the context of audcntl( ), it is the number of a system call, and it is passed with one of the HABITAT requests.

flags:

Arguments passed to system calls as flags. For example, in open( ), the value passed as the oflag argument.

gid:

The group ID.

home dir:

The home directory.

hostname:

A host name.

inode id:

An inode number. Along with inode dev, part of the descriptor information recorded for audit records involving activities with files.

inode dev:

The major and minor inode device numbers.

int param:

An integer value. For example, in setpgid( ), the process_id argument.

len:

An argument to mmap( ). The length of a region of memory.

login name:

The login user name.

long param:

A value of type long.

mask:

A mask argument. For example, in audcntl( ), the value passed with a SET_SYS_AMASK request.

object mode:

The protection mode of an object. For example, in open( ), the mode of the file being opened.

operation:

A request to audcntl( ), such as SET_SITEMASK.

pgrp:

A process group ID. For example, the process_group_id argument to setpgrp( ).

procname:

The process name associated with a PID.

prot:

An argument to mmap( ). The protections on a region of memory.

req mode:

The request mode. For example, in an open( ) O_CREAT, the protection mode for the new file.

request:

The security action requested in a call to security( ).

shell:

The user's shell program. Typically this record element appears in login event records.

username;

The user name associated with the event.

If the audit_tool -w option or the Audit Manager Translate UID/GIDs to Local Names selection was used to generate the audit report, then the user name might appear in parentheses. Parentheses indicate that the audit reduction tool had to use the getpw() routine to look up the user name in /etc/passwd. This happens in cases where the user name was not associated with the RUID at login time (for example, logins were not included among the audited events). See Section 10.5.3 for a description of dependencies among audit events.

10.8.2    Example Audit Record

The following is an example of an audit record:

audit_id:    1621       ruid/euid: 0/0   username: jdoe
pid:         5742       ppid: 1          cttydev: (39,0)
event:       login
login name:  jdoe
home dir:    /usr/users/jdoe
shell:       /bin/csh
devname:     tty02
char param:  Login succeeded
char param:  ZK33C5
directory:   /usr/users/jdoe
result:      0
ip address:  16.153.127.240 (alpha1)
timestamp:   Wed Jul 28 19:17:52.63 1996 EDT

10.8.3    Abbreviated Audit Records

The audit_tool -B command generates an audit report with an abbreviated record format.

An example of an abbreviated report:

AUID:RUID:EUID    PID    RES/(ERR)   EVENT
--------------    ---    ---------   -------------------------------------
-1:0:0            2056   0x0         execve (/usr/sbin/rlogind rlogind )
-1:0:0            2057   0x0         execve (/usr/bin/login login -p -h
                                             alpha1.sales.dec.com guest)
1234:0:0          2057   0x0         login  (guest)
1234:1234:1234    2057   0x0         execve (/bin/sh -sh)
1234:1234:1234    2058   0x0         execve (/usr/bin/stty stty dec)

Column headings for abbreviated reports:

AUID:RUID:EUID

The audit ID, real UID, and effective UID associated with the event.

PID

The process ID number.

RES/(ERR)

RES is the result number. Refer to the reference page for the specific system call for information about the result number.

(ERR) is the error code, if an error occurred. For a list of error codes and their meanings, see the reference pages for errno(2).

EVENT

The event and arguments appear in the last column.

The following information does not appear in the abbreviated report:

• User name (If you want the username instead of the AUID:RUID:EUID, use the audit_tool -wB command.)

• PPID

• Device ID

• Current directory

• Inode information

• Symbolic name referenced by descriptors

• IP address

• Time stamp

See the description of the -O option in the audit_tool(8) reference page to generate a customized brief report.

10.9    More About Generating Audit Reports

Audit reduction lets you process and filter data stored in the audit log and display the audit information in a format you can read.

From the CDE Dashboard, select the following:

Sysman Applications-->Daily Administration-->Audit Manager-->Reports-->Generate Reports

When generating reports with the Audit Manager graphical interface, you create a selection file that specifies such things as the events, times of day, AUIDs and other attributes of the audit records that you want included in the audit report.

From the command line, enter the following commands:

# audit_tool [-options] audit file name

For audit logs generated on an ULTRIX system, enter:

# audit_tool.ultrix

10.9.1    Filtering Out Specific Audit Records

Just as object selection and object deselection help you manage the size of audit logs by means of preselection, the audit reduction deselection feature can help you manage the size of audit reports. It supports the use of a deselection file to filter out audit records that you do not want to see.

A deselection file consists of one or more lines. Each line specifies a deselection rule in the following format:

[hostname audit_ID RUID event pathname flag]

An asterisk (*) in a field is a wildcard, which always gives a match. A string ending with a plus sign (+) matches any string that starts with the designated string. The flag specifies read (r) or write (w) mode for open events.

For example, to filter out all open operations for read access on objects whose pathname starts with /usr/lib/, specify the following line in the file:

* * * open /usr/lib/+ r
 

The lines that you specify in the deselection file take precedence over other selection options. You can create multiple deselection files, but you can specify only one deselection file each time you perform audit reduction.

Deselection files can be used with the CDE Audit Manager and with the following command:

# audit_tool -d deselection_file

10.9.2    Targeting Active Processes

This section shows how the auditmask and audit_tool commands can be used to get real-time audit data about a running process.

You can audit a process in real time by using the -p option to auditmask. Example 10-1 shows how you might investigate a process started by a user logged in as guest.

Example 10-1:  Sample Active Auditing Session

# ps -uguest -o user,pid,uid,comm          [1]
USER       PID   UID COMMAND
guest    23561  1123 csh
guest    23563  1123 ed
 
# auditmask -p 23563 open exec -c or       [2]
# auditmask -p 23563                       [3]
!  Audited system calls:
execv                      succeed  fail
exec_with_loader           succeed  fail
open                       succeed  fail
execve                     succeed  fail
 
!  Audited trusted events:
 
!  Audcntl flag: or
 
 
# auditd -d 5s -w                          [4]
Audit data and msgs:
  -l) audit data destination   = /var/audit/auditlog.hostname.001
  -c) audit console messages           = /var/audit/auditd_cons
  -d) audit data dump frequency        = 5s
 
Network:
  -s) network audit server status (toggle) = off
  -t) connection timeout value (sec)       = 4
 
Overflow control:
  -f) % free space before overflow condition = 10
  -o) action to take on overflow    = overwrite current auditlog
 
# audit_tool /var/audit/auditlog.hostname.001 -Bfw    [5]
USERNAME    PID    RES/(ERR)   EVENT
--------    ---    ---------   -----
jdoe        23563  0x4         open ( /etc/motd 0x0 )
jdoe        23563  0x4         open ( /etc/passwd 0x0 )
jdoe        23563  0x4         open ( /etc/ftpusers 0x0 )
jdoe        23563  0x4         open ( /etc/hosts 0x0 )
jdoe        23583  0x0         execve ( /usr/bin/sh sh -c ps )
jdoe        23583  0x5         open ( /usr/shlib/libc.so 0x0 )
jdoe      * 23592  0x0         execve ( /sbin/ps ps gax ) [6]
jdoe        23599  0x0         execve ( /usr/bin/sh sh -c w )
jdoe        23599  0x5         open ( /usr/shlib/libc.so 0x0 )
jdoe      * 24253  0x0         execve ( /usr/ucb/w w )
jdoe        23563  0x4         open ( savethis 0x602 0640 )
 
^C					  [7]
--interrupt:  exit (y/[n])?  y
#

1. Find out what process user guest is running and also get the process ID and audit ID. [Return to example]

2. For PID 23563, set the auditmask to open and exec, and perform an OR operation with the system mask. Note that exec is an alias for execv, exec_with_loader, and execve. [Return to example]

3. Get the auditmask for the 23563 process. [Return to example]

4. Dump to the audit log every 5 seconds and also show the auditd configuration. [Return to example]

5. Display a continuous (-f) abbreviated (-B) audit report. Resolve AUIDs to corresponding usernames (-w).

   Note that the name of the audit log was gotten from the results of the auditd -w command. [Return to example]

6. The asterisk (*) indicates an operation involving setuid. [Return to example]

7. Exit the audit_tool program with a Ctrl/C (auditing continues). [Return to example]

See the auditmask(8) reference page for more information.

10.10    Audit Data Recovery

In the event your system encounters a panic situation, the crashdc utility extracts any audit data left in the system at the time of the panic. The audit data is placed in the crash directory, in the audit-data.n file

The n is the crash number. If no audit data was present, the file is not created. The audit-data.n file can be processed with audit_tool.

It is possible for some audit records to appear in both the auditlog file and audit-data.n. It is also possible that the first audit record in audit-data.n may not be complete. The audit_tool utility marks this as a corrupted record. In this case, the audit record has already been written to the regular auditlog.

10.11    Implementation Notes

The following is information about the Tru64 UNIX auditing that you should be aware of:

• Some records show "NOTE: uid changed." This typically occurs in SETUID events, but may be seen anywhere when one thread changes the UID for all threads in a process (task).

• Audit records contain inode information and the file type of the object of the operation. So, for example, if a chmod command is specified for a symbolic link, the actual object referenced by the link is described.

• By design, some system calls can fail and not generate an audit record for the failure if the failure is not security-relevant. See Table 10-4 for a list of the calls.

• Only TIOCSTI operations are audited for the ioctl system call.

• Only F_DUPFD, F_SETTIMES, and F_CNVT are audited for the fcntl system call.

If the process audit control flag is set to USR, all ioctl and fcntl system calls are audited.

All security-relevant system calls can generate audit data, but when there is no security relevance, some system calls do not generate audit data. The conditions under which a particular system call does not generate an audit data are described in Table 10-4.

Table 10-4:  System Calls Not Always Audited

The system calls marked with an asterisk (*) typically generate audit data only for security-relevant options. When executing processes from auditmask with the -e or -E flag, however, all options generate audit data.

10.12    Responding to Audit Reports

Whenever you suspect an effort is being made to violate security, you should consider increasing the frequency of auditing. Additionally, you might want to tailor the list of events being audited to gather more specific information about the attempted violations. For example, if the attacks are against the file system, you might want to log all failed and successful file opens and closes, links, unlinks, chdirs, chmods, chowns, and other file-related activities.

When the audit trail implicates a specific authorized user in attempts to violate security, you can take the following steps:

• Talk with the user, reminding him or her of the importance of maintaining security and the need for all users to contribute to that effort.

• Restrict the user's access to the system by placing the user in a group of one.

• In extreme cases, deny the user system access by removing the user's account. This can be on a temporary or permanent basis.

• Audit the offending user's activities for indications that the user's behavior has changed. When you extract audit information, pay close attention to activities associated with the user's audit ID, UID, RUID, and user name.

  User-specific audits can be done from the screen: Audit Manager --> Reports --> Generate Reports, or with the audit_tool options -a AUID, -u UID, and -U username.

If the audit trail indicates attempts to violate security but points to no specific user, it is possible that you are faced with intrusion by an outsider. Your responses must then be directed to the system and the larger user community. In this case you can take the following steps:

• Have users change their passwords and inform them about the selection of safe passwords.

• Hold meetings with users to discuss the importance of system security.

• Increase physical security to make sure that only authorized users can gain physical access to the system.

• Perform backups of the file system more frequently, to minimize the damage if a break-in should occur and data on the system is lost or altered.

• If attacks seem to be coming in over a network, increase the auditing of network-related activities.

10.13    Using Audit to Trace System Calls

The audit mechanism can be used to troubleshoot system problems by collecting system call trace data.

Some differences exist between audit system call tracing and conventional system call tracing packages such as truss and trace. One difference is that audit system call tracing provides only the security-relevant arguments for each system call. See Section 10.13.3 to learn how to modify the kernel to get more data for a system call. Conventional trace packages attempt to capture all system call arguments.

Another difference is that audit system call tracing provides information unavailable from conventional tracing packages. Such information includes the following:

• Inode ID

• Thread ID

• File mode

• File descriptor to pathname translation

Also, audit works without requiring control of the target process.

10.13.1    Tracing a Process

To use the audit subsystem to trace a process, do the following:

1. Insure that the audit subsystem is configured and running.

2. Initially, set the auditmask to audit no events:

   auditmask -n

3. Use the auditmask -c option to set the process audcntl flag as appropriate.

4. If tracing a currently running process, use the auditmask -c usr option to trace all options for these system calls.

The following examples demonstrate the use of the auditmask utility (these examples modify the process auditmask; unless specified, the process audcntl flag remains at its default setting of or).

In the following example, audit records are created for everything done by the newly executed command program with its associated arguments:

	# auditmask -E command argument

In the following example, audit records are created for failed open system calls and successful ipc events (defined in /etc/sec/event_aliases) for the newly executed command program:

	# auditmask open:0:1 ipc:1:0 -e command arguments

In the following example, for PID 999, audit all (-f) events except gettimeofday:

	# auditmask -p 999 -f gettimeofday:0:0

In the following example, get the set of events being audited for PID 999:

	# auditmask -p 999

In the following example, set the audcntl flag of PID 999 to usr:

	# auditmask -p 999 -c usr

In the following example, for all processes owned by the user with AUID 1123, audit all ipc events (the AUID is the same as the user's initial RUID):

	# auditmask -a 1123 ipc

The auditmask -h command displays help for the command. See also the auditmask(8) reference page.

10.13.2    Reading the Trace Data

Use the following procedure to read the trace data collected by the audit mechanism:

1. Use auditd to flush any buffered audit data as follows:

   	# auditd -dq
   

   The -q option gets the name of the data file

2. Examine the data file with the audit_tool utility as follows:

   # audit_tool `auditd -dq` -B
    
    
   

See the audit_tool(8) reference page for further information.

10.13.3    Modifying the Kernel to Get More Data for a System Call

The audit subsystem normally collects the following data:

• System call name

• Result

• Error

• Timestamp

• ID information

• Various arguments passed to the system call

Only the arguments that are of interest from a security perspective are recorded. If additional arguments are required, you can use dbx to change which arguments get recorded for any system call. For example, flock is system call #131, and takes as arguments a file descriptor and an option. To audit these arguments, enter the following dbx commands:

     (dbx) a sysent[131].aud_param[0]='c'
     99
     (dbx) a sysent[131].aud_param[1]='a'
     97

The first entry in the aud_parm array corresponds to the first system call argument, the second entry corresponds to the second system call argument, and so on. The c encoding indicates a file descriptor is recorded. The a encoding indicates an integer argument is recorded. The set of encodings is described in the <sys/audit.h> file.

10.14    Traditional UNIX Logging Tools

For security-relevant auditing, use the audit subsystem. Traditional UNIX operating system logging tools are available and do provide some auditing capabilities for the following categories of events:

• Local login and logouts

• File Transfer Protocol (FTP) logins

• External logins and logouts for TCP/IP (rlogin and telnet)

• External logins and logouts for DECnet (dlogin and set host)

• Failed logins

• Failed attempts to become superuser (the su command)

• Reboots and crashes

• rsh and rcp file transfer requests

• DECnet file transfer requests

Auditing for each of these categories involves a data file, that stores the pertinent information, and a method for viewing the stored data. In some cases this method is a specific command, such as last or lastcomm. In other cases the contents of the file are viewed directly, for example, with the more command.

The accounting data is stored in a number of different files. Table 10-5 lists those files in the /var/adm directory. The presence of specific log files on your system depends on which logging and accounting features you have enabled.

Table 10-5:  Traditional UNIX Log Files in /var/adm

Protect the contents of these files. The files and directories should be owned by the root account, and they should not be writeable by group or other.

For a discussion of traditional UNIX accounting software, see the System Administration manual.