Chapter 20 BSM (Overview)

The Basic Security Module (BSM) provides two security features. The first feature is an auditing mechanism, 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 devices or assignable devices.

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

• What Is Auditing?

• How Does Auditing Work?

• How Is Auditing Related to Security?

• BSM Terminology

• Device Allocation

What Is Auditing?

Auditing is the collection of data about the use of machine resources. The audit data 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, all user actions are tracked with the same audit ID. See the su(1M) man page.

The auditing subsystem makes the following possible:

• 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 which users are using root capabilities

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 specific groups. You can examine all records for a certain type of event on a specific day. Or you can 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 system shutdown

• Login and logout

• Process creation or process destruction, or thread creation or thread destruction

• Opening, closing, creating, destroying, or renaming of objects

• Use of root capabilities or role capabilities

• 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 captured, 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?

To secure a computer system, especially a system on a network, is complex. Security requires mechanisms that control activities before system processes or user processes begin. Security requires tools that monitor activities as the activities occur. Security also requires reports of activities after the activities have happened. Initial configuration of Solaris 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 Solaris auditing monitors and reports these events is discussed in detail in Chapter 21, Audit Planning and Chapter 22, Managing the BSM Service (Tasks).

Auditing cannot prevent hackers from unauthorized entry. However, the audit subsystem can report, for example, that a specific user performed specific actions at a specific time and date. The audit report 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, the audit subsystem provides data that helps you determine the following:

• How system security was compromised

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

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 kernel-level events and user-level events. Events that are generated by the kernel are called kernel-level events. Events that are generated by applications are called user-level events. Kernel-level events have a lower audit event number than a user-level event, as shown in the following table.

Kernel-Level Audit Events

Events that are generated by the kernel are system calls. System calls have audit 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 are outside the kernel. Application software generates user-level events. User-level events range in number 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 20–2 shows general categories of user-related events.

Nonattributable Audit Events

Most events are attributable to an individual user, but some events are not. Events are nonattributable if the events occur at the kernel-interrupt level, or if the events occur before a user is identified and authenticated. Nonattributable events are auditable. The following example lists two nonattributable events from the /etc/security/audit_event file:

153:AUE_ENTERPROM:enter prom:na
6156:AUE_mountd_mount:mount:na

AUE_ENTERPROM is a kernel-level na event. AUE_mountd_mount is a user-level na event.

Audit Classes

Each audit event is also defined as belonging to an audit class or classes. Audit classes are convenient containers for large numbers of audit events. When you preselect a class to be audited, you preselect for auditing all the events in that class. Audit classes are defined in the /etc/security/audit_class file. Each entry contains the name of the class, its audit mask, and its short name.

0x00000010:fc:file create
0x00000400:na:non-attribute

The mapping of audit events to classes is configurable. These configuration changes are made in the audit_event file.

An auditable event is recorded in the audit trail when you preselect an audit class for auditing that includes the specific event. There are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in Table 23–1. See also the audit_class(4) man page.

Audit Flags

Audit flags are the short names for audit classes. Audit flags are used in the audit_control file to specify machine-wide defaults for auditing on the machine. The audit_control file is described in The audit_control File.

You can make exceptions to the machine-wide auditing defaults for individual users. You put audit flags in a user's entry in the audit_user file. The audit flags are also used as arguments to the auditconfig command. See the auditconfig(1M) and audit_user(4) man pages.

Audit Records and Audit Tokens

Each audit record describes the occurrence of a single audited event. The record includes information such as who did the action, which files were affected, what action was attempted, and where and when the action occurred. For example, the following line shows an audit record when processed by the praudit command:

header,81,2,login - local,,Mon May  6 16:55:48 PDT 2002, + 486 msec
subject,root,root,other,root,other,378,378,0 0 example_machine
text,successful login
return,success,0

Audit records are collected in an audit file. The set of audit files from a machine or site is called the audit trail. For a description of how audit files are handled, see the audit.log(4) man page. Audit records can be converted to a readable format by the praudit command. For examples of praudit output, see The praudit Command. See also the praudit(1M) man page.

The type of information that is saved for each audit event is defined in 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 the event. The nature of the event determines which tokens are recorded. You can generate audit record descriptions with the bsmrecord command. The following output shows the structure of the audit record that is generated when the creat() system call is used. The lines beginning with header are the audit tokens.

creat
  system call creat                see creat(2)
  event ID    4                    AUE_CREAT
  class       fc                   (0x00000010)
      header
      path
      [attribute]
      subject
      return

For more information, see How to Display Audit Record Formats. For a description of the structure of each audit token, see Audit Token Formats. The audit.log(4) man page also lists the audit tokens.

Audit Directory

An audit directory holds a collection of audit files. A typical installation uses many audit directories. The three types of audit directories are as follows:

• Primary audit directory – A directory where the audit files for a system are placed under normal conditions.

• Secondary audit directory – A directory where the audit files for a system are placed if the primary directory is full or not available.

• Directory of last resort – A local audit directory that is used if the primary audit directory and all secondary audit directories are not available.

Device Allocation

The device-allocation mechanism enables you to restrict access to a device, such as a CD-ROM. Device clean scripts 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 (Tasks) or Device Allocation Reference.