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:
Monitor security-relevant events that take place on the host
Record the events in a network-wide audit trail
Detect misuse or unauthorized activity
Review patterns of access, and see the access histories of individuals and objects
Discover attempts to bypass the protection mechanisms
Discover extended use of privilege that occurs when a user changes identity
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:
System startup and shutdown
Login and logout
Process creation or destruction, or thread creation or destruction
Opening, closing, creating, destroying, or renaming of objects
Use of privilege, identification, and authentication actions
Discretionary Access Control (DAC) changes by a process or user
Installation-specific administrative actions
Audit records are generated from three sources:
By an application
As a result of an asynchronous event
As a result of a process system call
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". |