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

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.

It is important that you inform users of the purpose and, in general terms, the nature of the auditing performed on the system. Represent 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.

10.1.1    Files Used for Auditing

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

Table 10-1: Files Used for Auditing

10.1.2    Auditing Tools

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

• The audit subsystem, which has powerful features unique to the trusted Digital UNIX operating system. This is a better way to perform security-relevant auditing.

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

The Digital UNIX audit subsystem provides a choice of the events to be logged, flexible data reduction of the audit log, and ease of maintenance. The following commands are used with the audit subsystem:

audit_setup

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 and administers audit data storage.

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. They are discussed in greater detail later in this chapter.

The Digital UNIX audit subsystem records activities in any file at any location chosen by the system administrator. The default log file is /var/audit/auditlog.nnn, where nnn is the generation number of the file, a number between 000 and 999.

The subsystem is capable of recording a wide range of events. You can choose a list of events to log for all users and then add or remove events from that list on a per-user basis to tailor the logging to individual users. The audit_tool program enables you to filter the audit log file and produce reports focusing on the information you need.

10.2    Setting Up the Audit Subsystem

The following sections explain how to setup a basic audit subsystem.

10.2.1    Set Up Questions

Before setting up the audit subsystem, you need to make the following decisions about how it is to run on your system:

• Determine the location for your local audit data. (Section 10.4.1)

• Determine the action to be taken when the local audit log overflows. (Section 10.4.1.1)

• Determine if there is a need to store local audit data remotely or to receive remote audit data. (Section 10.7)

• Decide on a list of events and system calls to be logged. You might have more than one list if you are logging different events at different times. (Section 10.10)

• If you are going to require per-user audit profile setup or the dxaudit program, ensure that you have the optional enhanced security subsets (OSFC2SEC4xx for per-user audit profile and OSFXC2SEC4xx for dxaudit) installed. You can check as follows:

  $  ls -l /usr/.smdb./OSF*C2SEC4??.lk
-rw-r--r--  1 root  system  0 Nov  8 11:02 \
                              /usr/.smdb./OSFC2SEC400.lk
-rw-r--r--  1 root  system  0 Nov  8 11:08  \
                              /usr/.smdb./OSFXC2SEC400.lk
  

  The presence of the lock files (OSFC2SEC400.lk and OSFXC2SEC400.lk) indicates that the enhanced security subset is installed on your system.

• Decide if you are going to setup audit using the audit_setup script or manually setup audit using the audit utilities. Using the audit_setup script is the recommended method.

10.2.2    Using the audit_setup Script

The audit_setup script configures your default audit subsystem. It sets parameters for auditd and the auditmask, which are used by one of the rc3 scripts to start audit whenever your system goes to multiuser (run level 3). For details, see audit_setup(8).

If you use the audit_setup script, enter the following from the command line:

#  /usr/sbin/audit_setup

Example 10-1 shows a sample audit_setup session:

Example 10-1: Using the audit_setup Script

********************************************************************

 

		Audit Subsystem Setup Script

 

********************************************************************

 

  The following steps will be taken to set up audit:
    1) establish startup flags for the audit daemon,
    2) establish startup flags for the auditmask,
    3) create the /dev/audit device (if needed),
    4) configure a new kernel (if needed).

 

  Do you wish to have security auditing enabled as part of
  system initialization (answer 'n' to disable) ([y]/n)?  y

 

    ----------------------------
     Audit Daemon Startup Flags
    ----------------------------

 

  Some of the options to 'auditd' control:
    1) destination of audit data,
    2) destination of auditd messages,
    3) action to take on an overflow condition,
    4) enable accepting audit data from remote auditd's.

 


 

  Destination of audit data (file|host:) [/var/audit/auditlog]? [Return]
  Directory /var/audit/ does not exist; create it now (y/[n])?  y
  Destination of auditd messages [/var/audit/auditd_cons]?  [Return]
  Action to take on an overflow condition may be one of:
    1)  change audit data location according to '/etc/sec/auditd_loc'
    2)  suspend auditing until space becomes available
    3)  overwrite the current auditlog
    4)  terminate auditing
    5)  halt the system
  Action (1-5) [1]?  [Return]
    List in '/etc/sec/auditd_loc' the alternate directories in 
    which to store audit data, and host names to which to send data.
    Do you wish to edit /etc/sec/auditd_loc now (y/[n])?  [Return]
  Accept data from remote auditd's (y/[n])?  y
    Don't forget to place names of remote hosts from which data
    may be accepted into '/etc/sec/auditd_clients'.
    Do you wish to edit /etc/sec/auditd_clients now (y/[n])?  y
?auditd_clients
a
alpha1
alpha1.sales.dec.com
.
1,$n
1		alpha1
2		alpha1.sales.dec.com
w
q
  Further options are available for advanced users of the audit system
  (please refer to the auditd manpage).  If you wish to specify any
  further options you may do so now (<Return> for none):  [Return]
  Startup flags for 'auditd' set to:
    -l /var/audit/auditlog -c y -o changeloc -r -s
  Is this correct ([y]/n)?  y
    -------------------------
     Auditmask Startup Flags
    -------------------------
  The auditmask establishes which events get audited.  This can be
  specified by:
    1) having the auditmask read a list of events from a file,
      -or-
    2) specifying a list of events on the command line.
  Events can refer to syscalls, trusted events, site-defined events, or
  alias names.
  The file '/etc/sec/audit_events' contains a list of all auditable
  system calls and trusted (application) events.  You may either
  modify this file or use it as a template.
  The file '/etc/sec/event_aliases' contains a set of aliases by which
  logically related groupings of events may be constructed.  You may
  modify this set of aliases to suit your site's requirements.
  Please enter the filename containing the event list or enter * to
  indicate that the individual events will be specified on the command
  line, or enter <Return> for no events:  /etc/sec/audit_events
  Do you wish to edit /etc/sec/audit_events now (y/[n])?  [Return]
  The auditmask also sets various style flags such as:
    1) 'exec_argp'   - audit argument vector to exec system calls
    2) 'exec_envp'   - audit environment vector to exec system calls
    3) 'login_uname' - audit recorded username in failed login events
  Enable exec_argp ([y]/n)?  [Return]
  Enable exec_envp (y/[n])?  [Return]
  Enable login_uname ([y]/n)?  [Return]
  Startup flags for 'auditmask' set to:
     -s exec_argp -s login_uname < /etc/sec/audit_events
  Is this correct ([y]/n)?  [Return]
    ----------------------
     System Configuration
    ----------------------
  Configuration file name (/sys/conf/ALPHA1)? [Return]
  Checking booted kernel '/vmunix' and config file '/sys/conf/ALPHA1'....
  /vmunix on ALPHA1 is already configured for security auditing.
  Would you like to start audit now ([y]/n)?  [Return]
    '/usr/sbin/auditd' started.
    '/usr/sbin/auditmask' set.
  ***** AUDIT SETUP COMPLETE *****
#

# 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.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.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 )
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 )
jdoe        23563  0x4         open ( savethis 0x1 )
jdoe        23563  0x4         open ( /tmp/edtmpAA 0x602 100640 )
jdoe        23563  0x4         open ( savethis 0x601 0640 )
jdoe        23563  0x5         open ( /tmp/edtmpAA 0x0 )

 

^C					  [6]
--interrupt:  exit (y/[n])?  y
#

All of the security-relevant audit data is collected in the auditlog.nnn file. Because of possible system configuration differences, the default location is different depending on how the audit subsystem is setup. If it is setup using the audit_setup script, the default location is at /var/audit/auditlog.nnn; if audit is setup using the auditd, the default location is at /var/adm/auditlog.nnn. In either case, the administrator can choose another location and file name.

The audit daemon increments the number, nnn, by one each time a new audit log is created. Some of the circumstances that cause the creation of a new audit log are as follows:

• A new log is requested (auditd -x) either by the system administrator or from crontab.

• Auditing is started.

• An overflow condition occurs.

10.4.1.1    Audit Log Overflow

When the file system for the current audit log fills to the specified level, a warning message is displayed at /dev/console or the specified audit console, and auditd takes its overflow action. You can specify the action to be taken when the audit log overflows by using either the audit_setup script or the auditd -o command. The actions you can take are as follows:

• Change to the next directory or host as specified in the /etc/sec/auditd_loc file.

• Suspend auditing.

• Overwrite the current audit log file. This causes the loss of previously logged audit data.

• Terminate the audit daemon.

• Halt the system.

The -o changeloc option to auditd allows the administrator to specify a list of directories or hosts to which auditd can store data. The auditd program on the host machine determines the path. If auditd reaches the "virtual limit," which is established with the -f option, it continues to output data into the next directory or host as specified in the /etc/sec/auditd_loc file. (The directories specified in /etc/sec/auditd_loc should be on different disk partitions.) If auditd cycles through all the directories listed in the /etc/sec/auditd_loc file, it will continue to output data into the last specified directory until the physical limit of the directory is reached.

When auditd fails because it has filled the last directory or cannot overwrite the log file, as specified by auditd -o overflow, the system shuts down with the following console message:

% auditd: overflow condition -> shutdown

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

10.4.1.2    Remote Audit Logs

Audit data can be sent to another system or can be received from other systems. The -l flag to auditd specifies a remote host to receive the audit data. If the remote site stops receiving, the local daemon stores its data locally as specified with the -o and -r flags to auditd.

The -s flag to auditd allows the audit daemon to accept audit data from other audit daemons whose host names are specified in the file /etc/sec/auditd_clients. The /etc/sec/auditd_clients file is site-specific and lists one host name per line.

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

10.4.2    Console Messages

Console messages generated by auditd are directed to a log file named auditd_cons. The default location is /var/audit/auditd_cons. You can choose a different location using the audit_setup script.

10.4.3    Creating Your Own Log Entries

By using the audgen command, you can include a message of your choosing in the audit log. The command builds an audit record consisting of user-supplied text and the audit ID, UID, PID, IP address, and timestamp. For example, if you wanted to annotate the log file, you might want to create an entry like the following:

#  /usr/sbin/audgen "Begin recording file opens by J. Doe."

You must enclose the audit log text in quotation marks or each word in the text will appear on a separate line when the text is later retrieved by the audit tool.

To log the event, AUDGEN8 must be one of the events designated for auditing with the auditmask. To extract records logged with the audgen command, include audgen in the list of events to be retrieved by the audit_tool command.

See the audgen(8) reference page.

10.5    Configuring the Audit Subsystem Using auditd

Although using the audit_setup script is the recommended way to configure your audit subsystem, you may want to do some tasks manually using the audit subsystem daemon, auditd.

10.5.1    Displaying Information About the Audit Subsystem

The auditd command provides several ways to obtain information about the audit subsystem:

• To display a brief help menu, use the -h option.

• To learn the location of the current audit log file, use the -q option.

• To learn the current options specified for the audit daemon, use the -w option.

10.5.2    Designating the Location of the Audit Log File

To designate the local pathname to which audit data is written, use the -l option to auditd followed by the pathname you want for the audit log. The file name should be of the form auditlog[.nnn], where nnn can be a number from 000 to 999, inclusive. The audit daemon appends the number automatically, incrementing the number by one each time a new audit log is generated. If you specify the number, the range is from the specified number to 999. For example, to create a new series of unique log files with the base name special_log, enter the following:

#  auditd -l /var/audit/special_log

By specifying a remote host as the argument to the -l option, you can send the audit data generated locally to a remote host running the audit daemon. For example, to send the your audit data to a remote host named peanuts, enter the following:

#  auditd -l peanuts:

The remote daemon sets the path to the audit log on the remote system.

10.5.3    Designating a Fallback Location for Audit Data

The auditd -r command reads a list of local directories or host names into which auditd switches its audit log file when an overflow condition is reached. When sending data to a remote host, the directories are determined by the remote host's auditd. It is prudent to designate a fallback destination that is in a different file system than the one for the current audit log.

The list of fallback locations is maintained in the /etc/sec/auditd_loc file. The auditd_loc file is site-specific and lists one host name (in host: format) or one directory path per line. Example 10-3 is an example of what an /etc/sec/auditd_loc file might look like.

Example 10-3: Sample /etc/sec/auditd_loc File

host1:
host2:
/var/alternate/auditdata1
/var/alternate/auditdata2
/var/alternate/auditdata3

The -r option is used when the overflow action (-o option) is set to changeloc. The following example shows how to tell auditd the location of your fallback directories:

#  auditd -o changeloc -r

10.5.4    Designating a Destination for Audit Log Status Reports

To provide you with up-to-date information on the status of the audit log, the audit subsystem sends messages about such things as log overflow conditions and the rollover of the current log file to a new file. Use the auditd -c command followed by a pathname to specify a device or local file as the destination of those messages. For example, to direct the status reports for your audit logs to a file named /usr/staff/r0/jdoe/log_status, enter the following:

#  auditd -c /usr/staff/r0/jdoe/log_status

10.5.5    Protecting Against Audit Log Overflow

The audit subsystem enables you to protect against the possibility of lost audit information due to the log file filling all the available space of a disk partition. The auditd -o command followed by an action string lets you specify an action to be taken by the system in the event of an overflow condition. You can choose the following actions:

changeloc

Change to the next directory or host listed in the /etc/sec/auditd_loc file.

halt

Shut down the system.

kill

Terminate auditd (stops auditing).

suspend

Suspend auditing until space is made available.

overwrite

Overwrite the current log file.

For example, on an overflow situation, to cause the audit logs to be sent to the next directory or host listed in the /etc/sec/auditd_loc file, enter the following:

#  auditd -o changeloc

10.6    Starting Audit

The first invocation of /usr/sbin/auditd spawns the daemon; subsequent invocations detect that an audit daemon is already running and communicate with it, passing the specified option parameters. The first invocation of the daemon also turns on auditing for the system (audcntl).

You can start the audit daemon using just the auditd command with no options and can then configure the audit subsystem using the auditd command for each individual option as described in the following sections. You can also configure and start the audit subsystem from a single command that includes the configuration options. The following is an example of a combined configure and start audit command line:

#  auditd -o changeloc -c ~jdoe/log_status \
       -r /etc/sec/auditd_loc -l peanuts:/var/audit/special_log

10.6.1    Turning Off Audit

The auditd -k command stops the audit daemon, thus disabling the audit subsystem. For example, to immediately stop auditing, enter the following:

#  auditd -k

Avoid using this option during normal system operation.

10.6.2    Starting a New Audit Log

To start (or roll over) a new auditlog with the number of the current auditlog incremented by 1, use the -x option to auditd. When you use this option, the old audit log is automatically compressed by the compress command. You can do this while the audit subsystem is active.

The name of an audit log file is always appended with a generation number, which ranges from 000 to 999. If the current audit log is auditlog.275, the -x option creates a new file, auditlog.276, and begins writing audit data to it.

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 :
   

4. From the audit hub you can designate options for an audit daemon serving a remote host by using the auditd command as usual to specify the options. On this hub, you will have a dedicated auditd for each remote connection. Include the -p option to designate the ID of the remote audit daemon to receive the options. To learn the ID of an audit daemon serving a remote connection, enter the following commands:

   #  /usr/sbin/auditd -w
   

   MASTER AUDIT DAEMON SERVER:
   
    
   
   Audit data and msgs:
     -l) audit data destination       = /var/audit/auditlog.039
     -c) audit console messages       = /var/audit/auditd_cons
   
    
   
   Network:
     -s) network audit server status (toggle)   = on
     -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 DAEMON #1 SERVING vijy.research.dec.com:
   
    
   
   Audit data and msgs:
     -l) audit data destination = \
                    /var/audit/auditlog:vijy.research.dec.com.040
     -c) audit console messages       = /var/audit/auditd_cons
   
    
   
   Network:
     -t) connection timeout value (sec)   = 4
   
    
   
   Overflow control:
     -f) % free space before overflow condition = 10
     -o) action to take on overflow  = overwrite current auditlog
   
    
   
   

   #  /usr/sbin/auditd -p 1 -l /var/audit/vijy -dq

   /var/audit/vijy.041
   

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    Processing Audit Log Data

The audit_tool command enables you to process and filter data stored in the audit log and to display the audit information in a format you can read. The command handles both compressed and uncompressed files.

The audit_tool command has the following syntax:

/usr/sbin/audit_tool [ options ] filename

Use filename to designate the audit log from which audit information is to be extracted.

Within a single option type, audit records are returned for each use of the option. For example, assuming the name of the audit log is auditlog.100, you can retrieve the records of all open, close, and rename events using the -e option as follows:

#  /usr/sbin/audit_tool -e open -e close -e rename /var/adm/auditlog.100

When you mix different options, only audit records that match the specified attributes are returned. For example, to get reports on only open events that are also associated with user name smith, you can use the following command:

#  /usr/sbin/audit_tool -e open -U smith /var/adm/auditlog.100

The audit_tool command can be highly selective in the audit records it extracts. For example, the following command extracts only records of open, close, or rename events that are associated with user name smith or brown.

#  /usr/sbin/audit_tool -e open -e close -e rename -U smith \
                                                 -U brown auditlog.100

When specified without an argument, the audit_tool command displays a brief help message.

The following sections describe some often-used features of audit_tool. For a complete description, see the audit_tool(8) reference page.

10.8.1    Using audit_tool Interactively

To run audit_tool interactively, use the -i option, which displays each option, along with its current or default setting. Enter your choice, or press Return to accept the current setting or default.

When in interactive mode, the default is to retrieve all audit records.

10.8.2    Selecting Audit Records

You can select records that are associated with user identity in four ways:

• Select records by user name.

  Use the -U option to specify one or more user names. Records with user names that match your input are then returned. Note that a user name is associated with a log record only if the event login is audited (see Section 10.10.1). The default is all user names.

• Select records by effective UID.

  Use the -u option to specify one or more UIDs. Log entries for processes with effective UIDs that match your input are then returned. The default is all UIDs.

• Select records by real UID (RUID).

  Use the -r option to specify one or more RUIDs. Log entries for processes with RUIDs that match your input are then returned. The default is all RUIDs.

• Select records by audit ID (AUID).

  Use the -a option to specify one or more audit IDs. Log entries for processes with audit IDs that match your input are then returned.

10.8.3    Generating a Report for Each Audit ID

Use the -R option to audit_tool to generate an ASCII report for each audit ID associated with the events being logged. All events with a common audit ID are placed in a report with the name report.n, where n, is the actual audit ID. You can specify a file name prefix by using an argument to the -R option, such as -R foo_.

10.8.4    Selecting Audit Records Within a Time Range

Use the -t option to audit_tool followed by a time specification to designate a start time. Then only those records with a timestamp equal to or greater than that start time are selected. Use the -T option followed by a time specification to designate an end time. Then only records with timestamps equal to or less than that end time are selected. Use -t and -T together to limit the audit records retrieved to only those that occurred within a given period.

The format for start and end times is yymmdd[hh[mm[ss]]]. You can specify only one start time and one end time. The default is to select for all records.

10.8.5    Selecting Audit Records for Specific Events

Use the -e option to audit_tool to retrieve audit records that match a list of designated events and their success and failure status.

The event specification has the following syntax:

event [ : success : failure ]

In place of event, enter the name of the event or an event alias for which you want to retrieve information. The default list of all auditable events is in the /etc/sec/audit_events file (see Appendix B).

The event selection for record retrieval is the same as event selection of the auditmask command. In place of success enter the following:

1

To retrieve successful instances of the event.

0

To retrieve failed instances of the event.

In place of failure, enter the following:

1

To retrieve successful instances of the event.

0

To retrieve failed instances of the event.

If you do not specify success and failure extraction, both are included in the audit report.

For example, the following command retrieves audit information only for failed attempts to change file ownership:

#  audit_tool -e chown:0:1  filename

10.8.6    Performing Continuous Audit Reporting

Use the -f option (in conjunction with the -d option to auditd) to have the audit_tool program read the audit log continuously, generating a report as it goes. The log is read even after the end of the file is reached. This allows you to extract audit data as it is being written to the audit log, which gives you the current audit information as it is generated.

10.8.7    Selecting Audit Records for Process IDs

To retrieve records associated with specific process IDs (PIDs), use the -p option and enter the PIDs you are interested in. The default is to select for all process IDs. If the specified PID is negative, the absolute value of the PID is selected as well as any of the PID's descendants.

10.8.8    Filtering Out Specific Audit Records

You can create a deselection file to filter out audit records that you do not want to see. In this way, you minimize the number of records to review.

Create the file at any location and with your choice of a file name. Edit this file to add a line for each event to be filtered out. The lines have the following syntax:

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 use the audit_tool command. To filter audit data using a deselection file, include it on the audit_tool command line with the -d option as follows:

#  audit_tool ... -d  filterfile4

10.8.9    Processing ULTRIX Audit Data

The audit_tool.ultrix program displays audit reports on a Digital UNIX system from audit data collected on ULTRIX systems. With the exception of the -g and -G options (equivalent to the -v and -V options for audit_tool), audit_tool.ultrix is the same as audit_tool. See the audit_tool(8) reference page and Section 10.8 for more information.

10.9    Site-Defined Audit Events

The Digital UNIX audit subsytem allows sites to define their own audit events (referred to as site-defined events). This is useful for applications that want to generate records specific to their requirements.

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

10.9.1    System Administrator's Responsibilities

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 range for the site event numbers is between MIN_SITE_EVENT (defined in the <sys/audit.h> file) and INT_MAX (defined in the <machine/machlimits.h> file).

The site_events file contains one entry for each site-event. Each site-event entry may contain any number of subevents. Both preselection (see auditmask(8)) and postreduction (see audit_tool(8)) capabilities are supported for site events. Postreduction capabilities are also supported for subevents.

The syntax for the /etc/sec/site_events entries is as follows:

event_name event_number [ , subevent_name subevent_number ... ] ;

The following is an example of a /etc/sec/site_events file:

essence 2048,
    ess_read 0,
    ess_write 1;
rdb 2049,
    rdb_open 0,
    rdb_close 1,
    rdb_read 2,
    rdb_write 3;
decinspect 2050;

In the first entry, essence is the event, 2048 is the event number, ess_read is the first subevent, 0 is the first subevent number, ess_write is the second subevent, and 1 is the second subevent number.

10.9.2    Trusted Application Responsibility

The trusted application generates audit data using the audgenl routine. This routine gives the programmer control over what data appears in the audit log.

The following code fragment generates audit data from a rdb_close in a trusted application:

int event_num, subevent_num;

 

/* translate event name(s) into event numbers) */
if ( aud_sitevent_num ( "rdb", "rdb_close", &event_num,
                                                &subevent_num ) )
   printf ( "aud_sitevent_num failed\n" );

 

/* generate audit data */
else if (audgenl ( event_num, T_SUBEVENT, subevent_num, T_CHARP,
                                   "Trusted RDB V1.0", 0 ) == -1)
	perror ( "audgenl" );

It is recommended, although not required, that you include a T_CHARP and "event name" argument pair to audgenl(). This makes analyzing the audit data with audit_tool easier on a system that does not have the site_events file.

Example 10-4 is the audit record generated from the example code:

Example 10-4: Layered Product Audit Record

audit_id:    0             ruid/euid:   0/0      (username: root)
pid:         2394          ppid: 2265            cttydev: (6,0)
event:       rdb
subevent:    rdb_close
char param:  Trusted RDB V1.0
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Tue Mar 29 15:48:13.65 1994 EST

See Chapter 19, aud_sitevent(3), and audgenl(3) for more information.

10.9.3    Managing Your Own Audit Data

If you want to create your own audit log, use the audgen() system call in place of audgenl(). If the size argument given to audgen() is nonzero, the audit data is not passed into the system audit data stream, but is copied out to the userbuff specified in audgen(). The trusted application can then send the data in userbuff to a unique log file. You can read your audit log using the audit_tool utility. See the audit_tool(8) reference page for more information.

When audgen() is called, the system provides the following audit data:

• AUID, RUID, EUID

• PID, PPID

• Device

• Timestamp

• User name

• IP address

The application provides the balance of the audit data as specified in the arguments to audgen(). See the audgen(2) reference page for more information.

10.9.4    Changing the Site Event Mask

The site event mask is the kernel representation of the contents of the /etc/sec/site_events, just as the system syscall audit mask is the kernel representation of whatever file is passed into the auditmask command. Unlike the system call audit mask, which is of known fixed size, the size of the site event mask is determined by the customer. The size of the site event mask can be changed using the sysconfig command. The details, such as the # events per byte, default, minimum and maximum size are found in the System Tuning and Performance Management.

10.10    Suggested Audit Events

When deciding which system events to audit, you need to keep in mind that auditing uses system resources. Logging a large number of events to allow for in-depth auditing has a cost in terms of system performance.

The safest practice is to log all events at all times. But unless your system requires very thorough security protection, this is unnecessary. Typically, you can achieve an adequate level of protection by regularly logging a limited number of events and by performing deeper logging at more widely spaced intervals. This provides a reasonable level of auditing capability and minimizes the impact on system performance.

Note

If you vary the depth of logging, avoid signaling to the user community the times when the deep audits occur; otherwise, would-be violators, hoping to avoid detection, will avoid those times for their illicit activity.

You should audit the logout() event. This makes the audit_tool program run faster during postreduction.

10.10.1    Dependencies Among Audit Events

Some information in the audit log represents information based on previous audited events. For example, the LOGIN event associates a login name with an RUID. Subsequent occurrences of that RUID (for a given process) can then be associated with a login name. This 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

Other examples of state-dependent information include the mapping of file descriptors to pathnames, current directory, and process name.

If you are auditing events that use file descriptors (for example, close or ioctl) and you want to see the associated pathname in the audit record, it is necessary to have been auditing the event that associated the pathname with the file descriptor (for example, open, socket, or bind), as well as other events that manipulate the file descriptors (dup, dup2, or fcntl).

To see the current directory, it is necessary to audit the chdir and chroot events.

To see the process name, it is necessary to audit the exec event (execve, execv, or exec_with_loader).

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(), but you should then use the -F option to the audit_tool program.

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

10.10.2    Auditable Events

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

• System calls

• Trusted events

• Site-defined events

The events listed in the /etc/sec/audit_events file are the system calls that can be audited. See Appendix B for the default list of the system calls.

A trusted event is an event that is associated with a security protection mechanism; it does not always correspond directly to a system call. The AUDGEN8 and LOGIN trusted events correspond to the use of the audgen and login commands. A list of the other trusted events that relate to auditing and authentication activity 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.

audit_setup

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 next local log specified as the next path in the /etc/sec/auditd_loc (with auditd -r) or the default local path (/var/adm).

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.

For a description of the information contained in a report for login and other auth_events, see Section 10.11.2.2.

You may also define site-specific events for auditing. See Section 10.9 for more information on site-defined audit events.

10.11    Audit Reports

The trusted Digital UNIX operating system offers two programs to generate audit reports: dxaudit and audit_tool. dxaudit is a windows-based program that allows you to create selection files as well as the final report. The audit_tool program operates from the command line.

10.11.1    Generating Audit Reports with the dxaudit Program

The dxaudit program provides a graphical interface for the creation of audit reports.

The functions performed with the XIsso program have been moved to other GUIs. The XIsso program in this release is only an interface to the other GUIs and support for XIsso will be discontinued after this release.

10.11.1.1    Selection Files

The Modify Selection Files window found under the Reports menu item allows you to create and modify selection files. A selection file is used to select specific events for your audit reports. Only audit records that contain events and identification items that you specify are displayed. You can also specify a time range. Using selection files can speed up the review of your audit reports. See the online help for selection files for more information.

10.11.1.2    Deselection Files

The Modify Deselection Files window found under the Reports menu item allows you to create and modify deselection files. A deselection file is used to filter unwanted events from your audit reports. All audit records that contain events and identification items that you specify are suppressed. Any events listed in the deselection file take precedence over events in a selection file. Using deselection files can speed up the review of your audit reports. See the online help for deselection files for more information.

10.11.1.3    Reports

The Generating Reports window found under the Reports menu item allows you to generate audit reports. You can select the audit log to be reviewed as well as the selection and deselection files to be used as a filter. You can tailor the output format to your needs using this window. See the online help for reports for more information.

10.11.2    Generating Audit Reports with the audit_tool Program

The long format for an audit record returned by audit_tool is made up of information found in every audit record and of some information specific to the particular record.

The following information is common to every audit record:

• AUID, RUID, and EUID

• User name (if available)

• PID, parent PID

• Device where event occurred (major #, minor #)

• Event

• Result or error from event

• Host name on which event occurred

• Timestamp

The following is an example audit record.

[1]  audit_id:    1621      [2] ruid/euid: 0/0  [3] username: jdoe
[4]  pid:         5742      [5] ppid: 1         [6] cttydev: (39,0)
[7]  event:       login
   login name:  jdoe
   home dir:    /usr/users/jdoe
   shell:       /bin/csh
   devname:     tty02
[8]  char param:  Login succeeded
   char param:  ZK33C5
   directory:   /usr/users/jdoe
[9]  result:      0
[10] ip address:  16.153.127.240 (alpha1)
[11] timestamp:   Wed Jul 28 19:17:52.63 1993 EDT

The entries in every audit record are as follows:

1. The audit ID (AUID). [Return to example]

2. The real user ID (RUID) and the effective user ID (EUID). [Return to example]

3. The user's name. In the expanded (not the brief) report format, parentheses may be used around the user name. If the user name is not in parentheses, the user name is the name used at login time. If the user name is in parentheses, the name is the one associated with the RUID. [Return to example]

4. The process ID (PID). [Return to example]

5. The parent process ID (PPID). If a security violation occurs for an event that is the offspring of another event, the PPID allows you to trace back through a list of processes to the originating event, so you can learn the RUID and UID (and user) associated with the original event. [Return to example]

6. The device on which the event occurred. The record reports the major and minor numbers. [Return to example]

7. The event that was logged, such as login or chmod. This record reports information such as the login name and the home directory. [Return to example]

8. The parameter for the event; for example, if the event is the chmod system call, char param is the file name that was the argument for the system call. [Return to example]

9. If the event failed, the reason for failure. "Permission denied" is among the types of errors logged. For example, if a user attempted to access a file for which the user does not have permission, the audit report would contain the message "error: Permission denied". [Return to example]

10. The host name on which event occurred. [Return to example]

11. The timestamp for the event occurrence. [Return to example]

10.11.2.1    Audit Reports for System Calls

To extract records of execve and open system calls (the -e option) from the /var/audit/auditlog.000 file in long format, enter the following command:

#  /usr/sbin/audit_tool -e execve -e open -w /var/audit/auditlog.000

Example 10-5 shows a sample audit report for the open and execve system calls.

Example 10-5: Audit Report for System Calls

audit_id:    1621      ruid/euid: 1621/1621   (username: jdoe)
pid:         1304      ppid: 1249             cttydev: (6,2)
event:       execve
char param:  /sbin/cat
char param:  cat /etc/motd
vnode id:    8707  	vnode dev:   (8,1024)  	[regular file]
object mode: 0755
result:      0
ip address:  16.153.127.241 (alpha1)
timestamp:   Mon Aug 30 14:33:31.46 1993

 


 

audit_id:    1621      ruid/euid: 1621/1621   (username: jdoe)
pid:         1304      ppid: 1249             cttydev: (6,2)
procname:    /sbin/cat
event:       open
char param:  /etc/motd
flags:       0 : read
vnode id:    2284  	vnode dev:   (8,1024)  	[regular file]
object mode: 0644
result:      3 (0x3)
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Mon Aug 30 14:33:31.46 1993

 

	.
	.
	.

 


 

8 records output
8 records processed

10.11.2.2    Audit Reports for Trusted Events

To extract records of the auth_event and login trusted events from the file /var/audit/auditlog.000 and present them in long format, enter the following command:

#  /usr/sbin/audit_tool -e auth_event -e login \
                                    /var/audit/auditlog.000

Example 10-6 shows a sample audit report for the auth_event and login trusted events.

Example 10-6: Audit Report for Trusted Events

audit_id: 1592         ruid/euid: 0/0         username: jdoe
pid: 597               ppid: 1                dev: (5,2)
event:       login
login name:  jdoe
home dir:    /users/jdoe
shell:       /bin/csh
devname:     /dev/tty04
char param:  Login succeeded
directory:   /users/jdoe
result:      0
ip_addr:     191.5.6.67 (alpha1.sales.dec.com)
timestamp:   Wed Jan  5 15:44:08.47 1994

 


 

audit_id: 1592         ruid/euid: 1592/0      username: jdoe
pid: 24247             ppid: 597              dev: (5,2)
event:       auth_event
login name:  jdoe
 ...........
remote/secondary identification data --
login name:  root
 ...........
char param:  su
directory:   /users/jdoe
result:      0
ip_addr:     191.5.6.67 (alpha1.sales.dec.com)
timestamp:   Wed Jan  5 15:44:25.24 1994

A remote system name is present if the login was done remotely. The remote system name is the LAT server name if the line is a LAT line. The remote system name is the host name if the login is by rlogin. There is always either an error: field or a result: field. It corresponds to the exit code that login exits with. The result is zero only when login was successful.

If login fails, the reason for the failure is given.

10.11.2.3    Audit Reports for Process IDs

To extract records of events with a process ID of 1304 from the file /var/audit/auditlog.000 and present them in long format, enter the following command:

#  /usr/sbin/audit_tool -p 1304 /var/audit/auditlog.000

Example 10-7 shows a sample audit report for the process ID of 1304.

Example 10-7: Audit Report for Process IDs

audit_id:    1621      ruid/euid: 1621/1621   (username: jdoe)
pid:         1304      ppid: 1249             cttydev: (6,2)
event:       execve
char param:  /sbin/cat
char param:  cat /etc/motd
vnode id:    8707  	vnode dev:   (8,1024)  	[regular file]
object mode: 0755
result:      0
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Mon Aug 30 14:33:31.46 1993

 


 

audit_id:    1621      ruid/euid: 1621/1621   (username: jdoe)
pid:         1304      ppid: 1249             cttydev: (6,2)
procname:    /sbin/cat
event:       open
char param:  /etc/motd
flags:       0 : read
vnode id:    2284  	vnode dev:   (8,1024)  	[regular file]
object mode: 0644
result:      3 (0x3)
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Mon Aug 30 14:33:31.46 1993

10.11.2.4    Abbreviated Audit Reports

To extract audit records about the execve and login commands from the /var/audit/auditlog.000 file and present the report in abbreviated format (the -B option), enter the following command:

#  /usr/sbin/audit_tool -B -e execve -e login /var/audit/auditlog.000

Example 10-8 shows a sample abbreviated audit report for the execve and login commands.

Example 10-8: Abbreviated Audit 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)
1234:1234:1234    2059   0x0         execve (/usr/bin/tset tset -I -Q)
1234:1234:1234    2060   0x0         execve (/usr/bin/hostname hostname)
1234:1234:0       2061   0x0         execve (/usr/bin/ps ps gax)
1234:1234:1234    2062   0x0         execve (/usr/bin/ls ls -l)
1234:1234:1234    2063   0x0         execve (/usr/bin/who who)
1234:1234:1234    2066   0x0         execve (/usr/bin/csh csh)
1234:1234:1234    2067   0x0         execve (/usr/bin/ls ls -a)
1234:1234:1234    2068   0x0         execve (/usr/bin/cat cat .cshrc)
1234:1234:1234    2069   0x0         execve (/usr/bin/from from)
1234:1234:0       2072   0x0         execve (/usr/bin/mail mail
                                                    guest@alpha1)
1234:1234:0       2072   0x0         execve (/usr/lib/sendmail -sendmail
                                                          guest@alpha1)
1234:1234:0       2077   0x0         execve (/usr/sbin/mailq
                                                       /usr/sbin/mailq)
1234:1234:1234    2078   0x0         execve (/usr/bin/rwho rwho)
1234:1234:0       2079   0x0         execve (/usr/bin/ps ps gax)
1234:1234:1234    2082   0x0         execve (/usr/bin/dbx dbx -k /vmunix)
1234:1234:1234    2095   0x0         execve (/usr/sbin/netstat
                                                /usr/sbin/netstat)
1234:1234:1234    2096   (err 13)    execve (/usr/sbin/auditd)
1234:1234:1234    2097   (err 13)    execve (/usr/sbin/auditmask)

 

The column headings of the report indicate the following:

AUID:RUID:EUID

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

PID

The process ID number.

RES

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

ERR

The error code. For a list of error codes and their meanings, see the reference pages for errno(2).

EVENT

The event and some arguments appear in the last column.

To extract records about the execve and login commands from the file /var/audit/auditlog.000 and present the report in abbreviated format, but with the user name displayed (the -w option) instead of the ID number, enter the following command:

#  /usr/sbin/audit_tool -wB -e execve -e login /var/audit/auditlog.000

Example 10-9 shows a sample abbreviated audit report for the execve and login commands as shown in Example 10-8, with user names displayed instead of ID numbers.

Example 10-9: Abbreviated Audit Report with User Names

USERNAME   PID   RES/(ERR)   EVENT
-----      ---   ---------   -------------------------------------------
root       2056   0x0        execve (/usr/sbin/rlogind rlogind)
root       2057   0x0        execve (/usr/bin/login login -p -h
                                            alpha1.sales.dec.com guest)
jdoe       2057   0x0        login  (guest)
jdoe       2057   0x0        execve (/bin/sh -sh)
jdoe       2058   0x0        execve (/usr/bin/stty stty dec)
jdoe       2059   0x0        execve (/usr/bin/tset tset -I -Q)
jdoe       2060   0x0        execve (/usr/bin/hostname hostname)
jdoe     * 2061   0x0        execve (/usr/bin/ps ps gax)
jdoe       2062   0x0        execve (/usr/bin/ls ls -l)
jdoe       2063   0x0        execve (/usr/bin/who who)
jdoe       2066   0x0        execve (/usr/bin/csh csh)
jdoe       2067   0x0        execve (/usr/bin/ls ls -a)
jdoe       2068   0x0        execve (/usr/bin/cat cat .cshrc)
jdoe       2069   0x0        execve (/usr/bin/from from)
jdoe     * 2072   0x0        execve (/usr/bin/mail mail guest@alpha1)
jdoe     * 2072   0x0        execve (/usr/lib/sendmail -sendmail
                                                         guest@alpha1)
jdoe     * 2077   0x0        execve (/usr/sbin/mailq /usr/sbin/mailq)
jdoe       2078   0x0        execve (/usr/bin/rwho rwho)
jdoe     * 2079   0x0        execve (/usr/bin/ps ps gax)
jdoe       2082   0x0        execve (/usr/bin/dbx dbx -k /vmunix)
jdoe       2095   0x0        execve (/usr/sbin/netstat
                                         /usr/sbin/netstat)
jdoe       2096   (err 13)   execve (/usr/sbin/auditd)
jdoe       2097   (err 13)   execve (/usr/sbin/auditmask)

The column headings are the same as in Example 10-8 except for USERNAME, which is the name associated with RUIDs using the getpw* routines. If the login user name is not available, the RUID is provided. Also, the asterisk (*) in front of the PID column indicates that RUID and EUID are different from each other.

10.12    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 audit-data.n in the crash directory, where n is the crash number. If no audit data was present, the audit-data.n 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 the audit-data.n file. It is also possible that the first audit record in audit-data.n may not be a complete record (audit_tool marks this as a corrupted record). In this case, the audit record has already been written to the auditlog file (or to the remote host).

10.13    Implementation Notes

The following is information about the Digital 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 vnode 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-3 for a list of the calls.

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

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

10.14    Traditional UNIX Logging Tools

Although you are urged to use the Digital UNIX audit subsystem for security-relevant auditing, the traditional UNIX operating system logging tools 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 event 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 information about events on the system is stored in a number of different files.

Table 10-2 lists those files storing security-relevant information. The presence of specific log files on your system depends on which logging and accounting features you have enabled.

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

Because these files are your record of what has happened on the system, you should protect their contents. The files and directories should be owned by the root account and they should not be writeable by group or other.

For a complete discussion of the accounting software on your system, see the System Administration manual.

10.15    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.15.5 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.15.1    Installing Audit

Audit must be configured into the kernel. You can either build a kernel with the DEC_AUDIT option, or run the /usr/sbin/audit_setup script.

The audit_setup script does the following:

• Establish startup flags for the audit daemon

• Establish startup flags for the auditmask

• Create /dev/audit (if needed)

• Configure a new kernel (if needed)

Startup flags are stored in /etc/rc.config. It is recommended that you select all the defaults, with the following exceptions:

• When asked to create /var/audit, select y.

• When asked to choose the action to take on an overflow, choose the option to overwrite the current auditlog.

Note

When prompted for event list, enter Return to have no events audited by default.

If a new kernel must be configured, audit is enabled when the new kernel is booted. If the kernel already supports audit, the audit_setup script will optionally enable audit.

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

10.15.2    Enabling Audit

There are two steps are required to enable audit:

1. Start the audit daemon (auditd)

2. Using the auditmask command, specify the events for audit. (For purposes of tracing, this may be best left to default to the null set of events at this point.)

Audit can be enabled using any one of the following approaches:

• audit_setup enables audit if the kernel supports it

• The init script enables audit according to the RC.CONFIG flags (which previously had been set by audit_setup) as follows:

  	# /sbin/init.d/audit start
  

• Manually starting auditd. For example, to collect data in the file ./FILE.nnn(-l), return the location of data file (-q), and overwrite log on overflow condition (-o o) enter the following commands:

  	# auditd -ql FILE -l -o overwrite
  

To stop the collection of audit data, either clear the auditmask (for the system or any process whose auditmask you set), or turn off auditd:

	# auditd -k

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

10.15.3    Tracing a Process

You can use the auditmask utility to adjust the audit characteristics of the system, of a single process, or all processes associated with a user's AUID.

Whether or not an event generates an audit record is a function of the system auditmask, the process auditmask, and the process audcntl flag. Each auditmask is a bitmap for all the events. The process audcntl flag specifies one of the following:

or

Audit if the event is in either the system or the process mask

and

Audit if the event is in both the system and the process mask

off

Do not audit this process

usr

Audit if the event is in the process mask

The default audcntl flag setting is or.

Specifying which events are audited is done by naming a set of system calls, alias names, or both. Aliases are defined in (and may be added to) /etc/sec/event_aliases. An optional extension can be used to distinguish between successful and failed occurrences of any event as follows:

	open:1:0 specifies successful occurrences of open()
	open:0:1 specifies failed occurrences of open()

The following examples demonstrate 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 args

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 exec'd command program:

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

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

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

In the following example, for PID 999, audit no (-n) events:

	# auditmask -p 999 -n

In the following example, for PID 999, audit open and exec events:

	# auditmask -p 999 open exec

In the following example, for PID 999, add exit to the set of events being audited:

	# auditmask -p 999 exit

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

In the following example, get abbreviated help for auditmask:

	# auditmask -h

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

10.15.4    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:

   # auditmask -E date
   Sun Nov 26 19:17:52 EST 1995
   
    
   
   # audit_tool `auditd -dq` -B
   
    
   
   AUID:RUID:EUID PID   RES/(ERR)     EVENT
   -------------- ---   ---------     -----
   1123:0:0       6691  0x14          audcntl (0x7 0x0 0x14 0x0)
   1123:0:0       6691  0x0           execve (/sbin/date date)
   1123:0:0       6691  0x2000        getpagesize ( )
   1123:0:0       6691  0x2000        getpagesize ( )
   1123:0:0       6691  0x0           getrlimit ( )
   1123:0:0       6691  0x3ffc0004000 mmap (-1 0x7 0x3ffc0004000
                                        0x12 0x2000)
   1123:0:0       6691  0x0           getrlimit ( )
   1123:0:0       6691  0x3ffc0006000 mmap (-1 0x7 0x3ffc0006000
                                        0x12 0x4000)
   1123:0:0       6691  0x0           getuid ( )
   1123:0:0       6691  0x1           getgid ( )
   1123:0:0       6691  0xa68         read ( 3 )
   1123:0:0       6691  0x120000000   mmap (3 0x5 0x120000000
                                        0x102 0x4000)
   1123:0:0       6691  0x140000000   mmap (3 0x7 0x140000000
                                        0x2 0x2000)
   1123:0:0       6691  0x4           open (/shlib/libc.so 0x0)
   1123:0:0       6691  0xa68         read (/shlib/libc.so)
   1123:0:0       6691  0x3ff80080000 mmap (/shlib/libc.so 0x5
                                    0x3ff80080000 0x2 0x10e000)
   1123:0:0       6691  0x3ffc0080000 mmap (/shlib/libc.so 0x7
                                    0x3ffc0080000 0x2 0x10000)
   1123:0:0       6691  0x3ffc0090000 mmap (-1 0x7 0x3ffc0090000
                                        0x12 0x9bf0)
   1123:0:0       6691  0x0           close ( 4 )
   1123:0:0       6691  0x0           stat (/shlib/libc.so)
   1123:0:0       6691  0x0           set_program_attributes ( )
   1123:0:0       6691  0x0           close (3)
   1123:0:0       6691  0x2000        getpagesize ( )
   1123:0:0       6691  0x0           obreak (0x14000ea10)
   1123:0:0       6691  0x0           gettimeofday ( )
   1123:0:0       6691  0x3           open (
                                    /etc/zoneinfo/localtime 0x0)
   1123:0:0       6691  0x32e         read (
                                    /etc/zoneinfo/localtime)
   1123:0:0       6691  0x0           close ( 3 )
   1123:0:0       6691  0x1d          write ( 1 )
   1123:0:0       6691  0x0           close ( 0 )
   1123:0:0       6691  0x0           close ( 1 )
   1123:0:0       6691  0x0           close ( 2 )
   1123:0:0       6691  0x0           exit ( )
   
    
   
   
    
   
   
    
   
   
    
   
   # audit_tool `auditd -dq` -e exec
   
    
   
   audit_id:    1123       ruid/euid: 0/0
   pid:         6691       ppid: 6688            cttydev: (6,7)
   event:       execve
   char param:  /sbin/date
   char param:  date
   inode id:    7390       inode dev: (8,16384)  [regular file]
   object mode: 0755
   result:      0
   ip address:  16.140.128.241 (alpha1.research.dec.com)
   timestamp:   Sun Nov 26 19:17:52.77 1995 EST
   

Additional options are available to help select data of interest:

# audit_tool
Audit reduction tool usage: [options] logfile

 

Selection options:
   -a audit_id                -e event[.subevent][:succeed:fail]
   -E error# or error_string  -h hostname or ip address
   -p [-]pid                  -P ppid
   -r real_uid                -s string_parameter
   -t start_time              -T end_time - yymmdd[hh[mm[ss]]]
   -u uid                     -U username
   -v inode_id                -V inode's device-major#,minor#
   -x device-major#,minor#    -y procname
   -/ search-string

 

Control options:
   -b        Output in binary format
   -B        Output in abbreviated format
   -d file   Use specified deselection rules file
              (-D to print ruleset)
   -f        Keep reading auditlog (like tail -f)
   -F        Fast mode; no state data maintained
   -i        Interactive selection mode
   -o        Override switching logfile due to change_auditlog
   -O format Output in specified format
         {cpu,usec,time,username,userid,pid,ppid,tid,res,event}
   -Q        Suppress progress messages
   -R [name] Generate reports by audit_id
   -S        Sort audit records by time (for SMP only)
   -w        Map ruid, group #s to names using passwd, group tbls
   -Z        Display statistics for selected events

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

10.15.5    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 "c" encoding indicates a file descriptor is recorded. The "a" encoding indicates an the integer argument is recorded. The set of encodings is described in the <sys/audit.h> file.

10.15.6    System Calls Not Always Audited

Not every instance of each system call generates audit data. The conditions under which a particular system call does not generate an audit record are described in Table 10-3.

Table 10-3: System Calls Not Always Audited

All instances of any system call not in Table 10-3 generate audit data.

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.

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