test

System Administration Guide: Security Services

Chapter 22 BSM (Overview)

The Basic Security Module (BSM) provides two security features. The first feature is a security auditing system, which includes tools to assist with the analysis of the auditing data. The second feature is a device-allocation mechanism, which provides the required object-reuse characteristics for removable or assignable devices.

This chapter introduces the concepts behind BSM. This is a list of the overview information in this chapter.

What Is Auditing?

Auditing is the collection of data that provides a record of security-related system events. This data can then be used to assign responsibility to actions that take place on a host. Successful auditing starts with two security features: identification and authentication. At login, after a user supplies a user name and password, a unique audit ID is associated with the user's process. The audit ID is inherited by every process that is started during the login session. Even if a user changes identity (see the su(1M) man page), all user actions are tracked with the same audit ID.

Auditing makes it possible to do the following:

During system configuration, you select which activities to monitor. You can also fine-tune the degree of auditing that is done for individual users.

After audit data is collected, audit-reduction and interpretation tools allow you to examine interesting parts of the audit trail. For example, you can choose to review audit records for individual users or groups, to examine all records for a certain type of event on a specific day, or to select records that were generated at a certain time of day.

How Does Auditing Work?

Auditing is the generation of audit records when specified events occur. Most commonly, events that generate audit records include the following:

Audit records are generated from three sources:

Once the relevant event information has been selected, the information is formatted into an audit record. The record is then placed in a kernel buffer known as the audit queue. From this temporary location within the kernel, audit records are written to audit files. Where the audit files are located is determined by entries in the audit_control file. The location can include multiple partitions on the same machine, partitions on different machines, or partitions on machines on different but linked networks. The collection of audit files that are linked together is considered an audit trail.

Audit records accumulate in audit files chronologically. Contained in each audit record is information that identifies the event, what caused the event, the time of the event, and other relevant information.

How Is Auditing Related to Security?

Securing a computer system, especially a system on a network, involves mechanisms that control activities before system or user processes begin, that monitor activities as they occur, and that report activities after they have happened. While the setting up of auditing requires that parameters be set before users log in or machine processes begin, most auditing activities involve monitoring current events and reporting those events that meet the specified parameters. How auditing monitors and reports these events is discussed in detail in Chapter 23, Audit Planning and Chapter 24, Managing the BSM Service (Tasks).

Auditing cannot prevent hackers from unauthorized entry. However, auditing can report, for example, that a specific user performed specific actions at a specific time and date, and can identify the user by entry path and user name. Such information can be reported immediately to your terminal and to a file for later analysis. Thus, auditing provides data that helps you determine both how system security was compromised and what loopholes need to be closed to ensure the desired level of security.

BSM Terminology

The following terms are used to describe the BSM service. Some definitions include pointers to more complete descriptions.

Table 22–1 BSM Terms

Term 

Definition 

Audit class 

A grouping of audit events. Audit classes provide a way to manage a group of events. For more information, see Audit Classes.

Audit directory 

A repository of audit files. For a description of the types of audit directories, see Audit Directory.

Audit event 

A security-related system action that is audited. For a discussion of the types of audit events, see Audit Events.

Audit flag 

A variable that is used to determine which classes of events to audit and when to audit them. For more information about audit flags, see Audit Flags.

Audit policy 

A set of auditing options that you can enable or disable for a particular configuration. These options include whether to record certain kinds of audit data or whether to suspend auditable actions when the audit trail is full.

Audit record 

The data, that is stored in binary form, that describes a single audit event. An audit record is composed of audit tokens. For more information about audit records, see Audit Records.

Audit token 

A set of data, that is stored in binary form, that describes an attribute of an audit event, such as a process, a path, or other object. For descriptions of all the audit tokens, see Audit Token Formats.

Audit trail 

A collection of one or more audit files that might reside in separate audit file partitions.

Device allocation 

A mechanism that enables you to restrict use of a device, as well as to erase any leftover data after a device has been used. For a description of device allocation, see Device Allocation.

Audit Events

Security-relevant system actions can be audited. These auditable actions are defined as audit events. Audit events are listed in the /etc/security/audit_event file. Each auditable event is defined in the file by a symbolic name, an event number, a set of preselection classes, and a short description (see the audit_event(4) man page).

There are several categories of audit events. The primary distinction is between events that are generated by the kernel (called kernel-level events), and events that are generated by applications (called user-level events). Whether the event is generated by the kernel or by a user-level application determines the number range of the event number that identifies the event.

Table 22–2 Audit Event Categories

Number Range 

Type of Event 

1–2047 

Kernel-level audit events 

2048–65535 

User-level audit events 

 

2048–32767 

Reserved for SunOS user-level programs 

 

32768–65535 

Available for third-party applications

Kernel-Level Audit Events

Events that are generated by the kernel (system calls) have event numbers between 1 and 2047. The event names for kernel events begin with AUE_, followed by an uppercase mnemonic for the event. For example, the event number for the creat() system call is 4, and the event name is AUE_CREAT.

User-Level Audit Events

Events that are generated by application software (outside the kernel) range from 2048 to 65535. The event names begin with AUE_, followed by a lowercase mnemonic for the event. For example, the event number for the rlogin command is 6155, and the event name is AUE_rlogin. Table 22–2 shows general categories of user-related events.

Nonattributable Audit Events

Most events are attributable to an individual user, but not all. These events are known as nonattributable events. Events are nonattributable if they occur at the kernel-interrupt level or before a user is identified and authenticated. Nonattributable events are auditable as well. AUE_ENTERPROM (kernel-level event number 153), and AUE_mountd_mount (user-level event number 6156), are examples of nonattributable events. Check the /etc/security/audit_event file for the exact numbers of individual events.

Audit Classes

Each audit event is also defined as belonging to an audit class or classes. By assigning events to classes, you can more easily deal with large numbers of events. When you name a class, you simultaneously address all the events in that class. The mapping of audit events to classes is configurable. These configuration changes can be made in the audit_event file.

Whether an auditable event is recorded in the audit trail depends on whether you preselect a class for auditing that includes the specific event. The are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in Table 25–2.

Audit Flags

Audit flags indicate classes of events to audit. Machine-wide defaults for auditing are specified for all users on each machine by flags in the audit_control file, which is described in The audit_control File.

You can modify what is audited for individual users by putting audit flags in a user's entry in the audit_user file. The audit flags are also used as arguments to the auditconfig. See the auditconfig(1M) man page.

Audit Records

Each audit record describes the occurrence of a single audited event and includes information such as who did the action, which files were affected, what action was attempted, and where and when the action occurred.

The type of information that is saved for each audit event is defined as a set of audit tokens. Each time an audit record is created for an event, the record contains some or all of the tokens that are defined for it, depending on the nature of the event. You can generate audit record descriptions with the auditlist command. For more information, see How to Display Audit Record Formats. For a description of the structure of each audit token, see Audit Token Formats.

Audit records are collected in an audit trail (see the audit.log(4) man page) and can be converted to a readable format by the praudit command (see the praudit(1M) man page). See The praudit Command for details.

Audit Directory

An audit directory holds a collection of audit files. Many audit directories are used in a typical installation. The three types of audit directories are as follows:

Device Allocation

The device-allocation mechanism enables you to restrict use of a device, as well as to erase any leftover data after a device has been used. These actions increase the security of a device. For more information see Managing Device Allocation or Device Allocation Reference.