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:

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.

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

The system monitors changes in the status of the audit system, and information about that status is stored in an audit console file.

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.

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. 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.

Administrator Tasks

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

Configure the audit system

Select activities to be audited

Produce audit reports

Note

The per-user auditmask feature, which allows you to specify auditing of events on a user-by-user basis, requires the enhanced security subset OSFC2SEC5xx.
dxaudit, the graphic interface for audit, requires the software subset OSFXC2SEC5xx.
You can check for these subsets as follows:
> ls -l /usr/.smdb./OSF*C2SEC5??.lk
-rw-r--r-- 1 root system 0 Apr 6 09:37 /usr/.smdb./OSFC2SECxxx.lk
-rw-r--r-- 1 root system 0 Apr 6 09:43 /usr/.smdb./OSFXC2SECxxx.lk
The presence of the lock files (OSFC2SECxxx.lk and OSFXC2SECxxx.lk) indicates the subsets are installed.

10.1.1 Audit Files

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

Table 10-1: Files Used for Auditing

File Name	Security-Relevant Information
`/var/audit/auditlog.nnn`	Default log file for the audit subsystem when `audit_setup` is used to configure the audit system. `nnn` is a generation number between 000 and 999.
`/etc/sec/auditd_cons`	Default log file for messages from the audit subsystem.
`/etc/sec/audit_events`	A file listing all the system activities that can have security relevance. This file can be used as input to the `auditmask` command, which controls what gets audited on the system.
`/etc/sec/site_events`	A file defining site--specific audit events. It supports integrating application auditing into the audit subsystem.
`/etc/sec/event_aliases`	A file containing a list of aliases that represent sets of events that can be audited.
`/etc/sec/auditd_loc`	A list of alternate paths and hosts where audit logs can be stored if the current location beomes unavailable.
`/etc/sec/auditd_clients`	A list of the remote hosts that can send remote audit data to the local audit log.
`/cluster/members/{memb}/dev/audit`	CDSL required for audit on clustered systems.
`/cluster/members/{memb}/dev/.audit/audS`	CDSL required for audit on clustered systems.

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.nnn, where nnn is the generation number of the file, a number between 000 and 999.

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 Tru64 UNIX 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:

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 (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 Graphic Interface

The graphic interface to the audit subsystem is accessed using the CDE dashboard:

Application Manager --> System Administration --> Daily Administration --> Audit Manager

Configuration of the audit subsystem is done with the secconfig command. All other activities can be handled with the graphic interface. If you intend to use the graphic interface rather than the command-line interface, you'll still want to read Section 10.3.1 for an overview of the auditd command, but you can skip the other the command-line information in Section 10.3.

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

10.2 Quick Start

To get the audit system up and running quickly, do the following:

Decide on the primary location for the audit log. Because log files can become quite large, select a directory in an appropriate file system.

Copy /etc/sec/audit_events, the file containing a list of all security relevent audit events(you'll need to be running as root to have access to the file):
```
# cp /etc/sec/audit_events /etc/sec/events_to_audit
```
If you want to audit all security-relevant events, skip the next step.

Edit /etc/sec/events_to_audit to meet your site's auditing needs.

Lines in /etc/sec/events_to_audit should be of the form:


event      [succeed]   [fail]

Desired auditing for event	Format
Audit successful occurrences of an event:	`event_name` `succeed`
Audit failed occurrences of an event:	`event_name` `fail`
Audit both succeesful and failed occurrences of an event:	`event_name` `succeed fail`
Turn off auditing of an event:	`event_name`

Make a file named /etc/sec/auditd_loc. This file should be a list of alternate directories for the audit log. These alternate directories are used in the event that the current directory with the audit logs becomes unavailable.
For example, if the file system containing the current directory becomes full, the audit system closes that audit log and begins a new log in the first directory listed in /etc/sec/auditd_loc.
The content of /etc/sec/auditd_loc might look like
```
/usr/auditlogs
/etc/auditlogs
/archive/audit/logfiles
```

Run /usr/sbin/audit_setup.
Press the [Return] to take the defaults for all items except for the prompt for the filename of events:
```
Please enter the filename for the event list, or enter * to indicate
that individual events will be specified on the command line, or enter
(for no events):
 
```
Enter /etc/sec/events_to_audit. Then for remaining prompts, accept the preset values. Auditing starts when audit_setup is finished running.

Check the configuration of the audit subsystem by entering the command auditd -w. 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.001  [1]
-c) audit console messages                = /var/audit/auditd_cons  [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            = change to next auditlog location  [5]
    alternate auditlog locations          = alternate file systems  [6]
 
```
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 turned off. [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 switch the audit log to a different file system, one you designated in /etc/sec/auditd_loc. When the audit log is switched, the current log is closed and compressed. [Return to example]
6. In place of alternate file systems, the directory names you specified in /etc/sec/auditd_loc are displayed. [Return to example]

10.2.1 What to Do Next

If you do not like the current setup of the audit subsystem, you can change it at any time.

From the Command-line:

Reconfiguration Task	Command
To change the events being audited:	`auditmask` command
To change the configuration:	`auditd` command

For example, suppose you no longer want to audit reboot, but want to continue auditing the other events you initially specified:


# auditmask reboot:0:0

Suppose you want to add chown to the list of events currently audited:

# auditmask chown:1:1

To leave audit running, but turn off auditing of all events:

# auditmask -n

To turn auditing off (kill the audit daemon):

# auditd -k

Suppose you want the overflow condition to occur with 25% remaining disk space, instead of the current 10%:

#auditd -f 25

Or suppose you want audit messages to go to /dev/console instead of to the file/var/audit/auditd_cons:

# auditd -c /dev/console

For more information about the auditmask command, see the reference page for auditmask(8)

For more information about the auditd command, see Table 10-2 and the reference page for auditd(8)

With the Graphic Interface:

Audit configuration is done from the command line, with the auditd command. See the preceding examples.

To use the graphic interface to change the events being audited, from the CDE Audit Manager:

Collection --> Modify System Mask

10.3 Audit Commands

The auditd, auditmask and audit_tool commands are described here.

10.3.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

Configuration Task	Command
Turn auditing on	`auditd`
Turn auditing off	`auditd -k`
Designate location of audit log	`auditd -l` `pathname`
Configure the audit subsystem so that if a situation should arise where the current log cannot be written to, a new log will be started in a different location (first, you'll need to put a list of alternate path names in the file `/etc/sec/auditd_loc`)	`auditd -o changeloc`
Suspend auditing if the audit log cannot be written to	`auditd -o suspend`
Halt the system if the audit log cannot be written to	`auditd -o halt`
Enable the local system to accept audit data from foreign hosts. (first you must put a list of permitted hosts in `/etc/sec/auditd_clients)`	`auditd -s` (This command toggles network auditing. If network auditing is on, `auditd -s` turns it off. If it's off, `auditd -s` turns it on.)

10.3.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).

Selection Task	Command
Audit all events	`auditmask -f`
Don't audit any events	`auditmask -n`
Audit successes and failures of an event	`auditmask` `eventname` or `auditmask eventname:1:1`
Audit only successes of an event	`auditmask eventname:1:0`
Audit only failures of an event	`auditmask eventname:0:1`
Turn off auditing of an event Once an event is designated for auditing, auditing of the event continues until explicitly turned off.	`auditmask eventname:0:0`
Audit events as specified in a file. See `/etc/sec/audit_events` for an example of such a file.	`auditmask <` `filename`
Audit all processes generated by a specific user	`auditmask -a` `AUID-of-user`
Audit file activity only for certain files (Object Selection)	`auditmask -X` `filename` `filename` specifies a file containing a list of files for which acitvitiy will be audited.
Do not audit file activity for certain files (Object Deselection)	`auditmask -Y` `filename` `filename` specifies a file containing a list of files for which activity will not be audited.

10.3.3 Producing Audit Reports: the `audit_tool` Command

The following table gives examples of uses of the audit_tool command. For a complete description, see the audit_tool(8) reference page.

Generating Audit Reports

Report Task	Command
Generate a report for all activities that occurred during a certain time period:	`audit_tool -t` `start` `-T` `end` `auditlog` The `start` and `end` times are in the format `yymmdd[hh[mm[ss]]]`. Hours (`hh`), minutes (`mm`), and seconds (`ss`) are optional.
Generate a report for all failed attempts by a specific user to open files:	`audit_tool -U` `username` `-e open:0:1` `auditlog` If `login` is not preselected for auditing, then no usernamesappear in the auditlog. In this case, you can still select for UIDs (`audit_tool -u` `UID`) or AUIDs (`audit_tool -a` `AUID`).
Generate a report for each audit ID (AUID) in the audit log. The reports will be named `report`.`AUID`:	`audit_tool -R` `auditlog`
Generate a report of all audit records containing the text `string` in a parameter field or associated with a descriptor:	`audit_tool -s` `string`
Generate a report of all audit records associated with a specific process ID:	`audit_tool -p` `PID`
Generate a report of all audit records associated with a specific process ID and all the descendants of that process:	`audit_tool -p -PID`

10.4 What to Audit

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

System calls

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, do the following:

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

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

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

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

Set the auditmask to no events. [Return to example]

Restore the auditmask to the original events. [Return to example]

10.4.1 Trusted Events

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.
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).
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.4.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 file /etc/sysconfigtab. For example, to allow up to 5000 site--defined events, add the following lines to /etc/sysconfigtab:

 sec:
     audit-site-events=5000

Then reboot the system.

For a description of /etc/sec/site_events, see the reference page for site_events(4).

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.4.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 an 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

To get this state-dependent Information...	...audit these events
login username	login
process name	exec, execve, exec_with_loader
file name	open, socket, bind, dup, dup2, fcntl
current directory	chdir, chroot

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.4.4 Suggestions of Events to Audit

When deciding which system events to audit, keep in mind that auditing uses system resources. Auditing a large number of events can have a cost in terms of system performance.

The safest practice is to audit 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 auditing a limited number of events and by performing deeper auditing 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 auditing, 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.5 Preselection: Managing the Volume of Audit Data

Because a heavily used system can generate huge amounts of audit data when all events are audited, you need flexibility in controlling which events actively generate data. The audit subsystem provides tools to allow pin-point preselection of events for auditing and to easily change those preselections:

audit masks and control flags

event aliases

object selection and deselection

10.5.1 Audit Masks and Control Flags

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

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/[a-z]/username, 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 the enhanced security subset OSFC2SEC5xx

Audit Control Flag

The audit control flag mediates the interaction between the system audit mask and the process audit mask.

The audit control flag regulating system mask and process mask interaction can be set from the CDE dashboard:

Audit Manager --> Collection --> Modify Active Process Mask

From the command line, use the auditmask -c command

Interaction between system audit mask and process mask		Control flag value for `auditmask -c`
Generate audit record of an event if either the system mask or process mask specifies the event		`auditmask -c or`
Generate audit record of an event only if both the system mask and process mask designate the event.		`auditmask -c and`
No auditing for this process		`auditmask -c off`
Generate audit records based only on the process audit mask		`auditmask -c usr`

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 protected password database stores the value for the control flag.

The control flag for a user's login process is set through the CDE dashboard:

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

10.5.2 Event Aliases

An event alias groups multiple audit events events under a single name. You define an event alias in a 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/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 graphic interface.

See /etc/sec/event_aliases for an example of an alias file.

10.5.3 Object Selection and Deselection

Object selection and deselection are powerful tools for managing the growth of audit logs.

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.

Data access operations are:

    open          stat
    close         lstat
    link          dup
    lseek         revoke
    access        readlink
    fstat         dup2
    read          getdirentries

Object selection and deselection work as follows:

Selection

Object selection allows you to specify a set of files against which data access operations generate audit data. When object selection is active, audit records for data access operations are generated only the specified files. Those same operations on other files do not generate audit data.

For example, you can audit the opens of the /etc/passwd and /.rhosts files while not auditing open events of/tmp/xxxx files.

Deselection

Object deselection allows administrators to specify a set of files against which data access operations do not generate audit data. Accesses to other files are audited as usual.

File open's for write or truncate access, however, cannot be deselected.

The result is that it is now possible, for example, to not audit accesses to /usr/shlib/libc.so, but still audit the opening of the /etc/passwd file.

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

Use of object selection/deselection requires three steps:

Decide which file or files you want to apply object selection or deselection to. If you want to apply selection/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.

Set the auditstyle 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

Activate object selection/deselection:

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 fiel 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 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

Although the system object selection and object deselection audit stylesare 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 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:

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.

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
```

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.

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.7 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 if login fails, in which case "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 remains 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.

Note that AUID and LUID (login uid) are synonyms.

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.7.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, naming the copy sept_report the audit record will include the following: 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.

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 dirctory.

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:

Group ID.

home dir:

The home directory.

hostname:

A hostname.

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( ),

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.

obj il[sl]:

The information label and, optionally, sensitivity label of an object. For example, in read( ), the information label and sensitivity label of the file being read.

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( ).

policy:

The security policy to which a label belongs. This record element is associated with security( ), and appears in audit records for requests such as SEC_GETLABEL.

privs used:

The privileges used to perform an operation that requires privilege. For example, in read( ), if a process uses allowmacaccess to access a file to which it does not otherwise have MAC access.

privileges:

The privileges passed with a request to security( ). For example, with the request SEC_CHPRIVSYS - EFFECTIVE_PRIV, a request to change effective privileges.

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( ).

secevent:

A security event associated with an X window operation. For example, obj_IL_float.

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 username might appear in parentheses. Parentheses indicate that the audit reduction tool had to use the getpw() routine to look up the username in /etc/passwd. This happens in cases where the username was not associated with the RUID at login time (for example, logins were not included among the audited events). See Section 10.4.3 for a description of dependencies among audit events.

10.7.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.7.3 Abbreviated Audit Records

The -B option 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 errno(2) reference page.

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 user name instead of the AUID:RUID:EUID, use the -wB options to audit_tool.)

PPID

Device ID

Current directory

Inode information

Symbolic name referenced by descriptors

IP address

Time stamp

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

Application Manager --> System Administration --> Daily Administration --> Audit Manager --> Reports --> Generate Reports

When generating reports with the Audit Manager graphic interface, you'll create a selection file, which 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:

audit_tool [-options] audit file name

Or for audit logs generated on ULTRIX systems:

audit_tool.ultrix

10.8.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 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 ypu perform audit reduction.

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

audit_tool -d deselection_file

10.8.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.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 )
 
^C					  [6]
--interrupt:  exit (y/[n])?  y

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

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]

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

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

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]

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

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

10.9 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 file

audit-data.n

n is the crash number. If no audit data was present, the file is not created. audit-data.n 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.nmay not be complete. audit_tool marks this as a corrupted record. In this case, the audit record has already been written to the regular auditlog.

10.10 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 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-4 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.

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

System Call	Cause for No Audit Record
`close`	The system call failed because it was passed an invalid file descriptor.
`dup2`	The system call failed because it was passed an invalid file descriptor.
`execv, execve,`	`namei` lookups failed
`exec_with_loader`	A thread failed to terminate thread, ora handler callout aborted
`fcntl(*)`	The system call failed because it was passed an invalid file descriptor.
`ioctl(*)`	The system call failed because it was passed an invalid file descriptor.
`priocntlset()`	An invalid process was specified (ESRCH), or thecall did not modify another process.
`reboot()`	Successful reboots are not audited. The `reboot()` call does not return from a successful reboot.
`security()`	No audit record for the `getluid` option. This option has no security relevance, and if it were audited, many audit records of no use would result.
`swapctl()`	Only `SC_ADD` forms of the call are audited. Other forms have no security relevance.
`uadmin()`	Only a failed A_REBOOT or A_SHUTDOWN is audited. In other cases, the system is rebooted and the system call does not return.

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.11 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.12 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.12.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.12.1 Tracing a Process

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

Choose the audit daemon overflow option to overwrite the current auditlog:
auditd -o overwrite

Initially, set the auditmask to audit no events:
auditmask -n

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

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

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 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 exec'd 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.12.2 Reading the Trace Data

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

Use auditd to flush any buffered audit data as follows:
```
	# auditd -dq
```
The -q option gets the name of the data file

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

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

10.12.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 "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.13 Traditional UNIX Logging Tools

For security-relevant auditing, use the Tru64 UNIX 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

File Name	Security-Relevant Information
`wtmp`	Records all logins, logouts, and shutdowns. Use the `last` command to view this log.
`syslog.dated/date/daemon.log`	Messages generated by system daemons.
`syslog.dated/date/kern.log`	Messages generated by the kernel (for example, for system crashes).
`syslog.dated/date/lpr.log`	Messages generated by the line printer spooling system.
`syslog.dated/date/mail.log`	Messages generated by the mail system.
`syslog.dated/date/user.log`	Messages generated by user processes.
`syslog.dated/date/syslog.log`	Requests for DECnet file transfers.
`acct`	Raw system accounting data, including user commands .

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.