The following steps will be performed by the administrator to filter the audit events and control the audit trail file.
1. The administrator obtains the event numbers corresponding to the events represented by the code points in the bank server program from the programmer or from the program's documentation. These events and their assigned event numbers are as follows:
acct_open( )
0xC1000000
acct_close( )
0xC1000001
acct_withdraw( )
0xC1000002
acct_deposit( )
0xC1000003
acct_transfer( )
0xC1000004
2. The administrator decides to create two event classes: the account_creation_operations class comprised of acct_open( ) and acct_close( ), and the account_balance_operations class comprised of acct_withdraw( ), acct_deposit( ), and acct_transfer( ).
3. The administrator decides to create two filters: one for all users within the cell (for the cell /.:/torolabcell), and the other for all other users.
The filter for all users within the cell has the following guides:
a. Audit the events in the event class account_balance_operations only, subject to the next condition.
b. Write an audit record only if an operation in that event class failed because of access denial.
c. If the first condition is fulfilled, write the audit record in an audit trail file only.
The filter for all other users has the following filter guides:
a. Audit the events in both event classes, subject to the next condition.
b. Write an audit record if an operation in that event class succeeded or failed.
c, Write the audit record both in an audit trail file and the console.
The scenarios described here can be summarized as follows:
· The programmer identifies the code points in the distributed application corresponding to the audit events.
· The programmer uses the audit API functions on those code points to enable auditing.
· The administrator creates event classes that are used to group the audit events.
· The administrator creates filters to narrow down the conditions by which audit records are written for the audit events.
The following figure illustrates the interactions among the audit client program, the audit API functions (libaudit), the audit daemon (auditd), and the audit management interface (available from the DCE control program, dcecp).
Overview of the DCE Audit Service
The audit management interface (accessed through the DCE control program) is used by the systems administrator to specify who, what, when, and how to audit. This is accomplished through the use of the filters. The audit daemon maintains the filter's information in its address space. The filters are also stored in local files so that the filters can be restored when the machine restarts, and so that audit clients can read the filter information from these files.
The audit clients are the users of the filter information. Using the audit APIs, the audit client reads the information on filters and event class configuration. The audit client reads these files only once, unless an update notification is received from the audit daemon (which is triggered by an update initiated by an administrator using the DCE control program).