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

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

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.
There are several categories of audit 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.

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

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.

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. Audit records can be converted to a readable format by the praudit command.
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.

How to Enable Auditing
This task starts the auditing service. If the service has been configured, then rebooting the host also starts the service.
1. Become superuser or assume an equivalent role.
2. Bring the system into single-user mode.

# /etc/init 1
3. Run the script to configure the system to run auditing.
Go to the /etc/security directory, and execute the bsmconv script there. The script sets up a standard Solaris machine to run auditing after a reboot.

# cd /etc/security
# ./bsmconv
4. Bring the system into multiuser mode.

# /etc/init 6
5. The startup file /etc/security/audit_startup causes the audit daemon to run automatically when the system enters multiuser mode.

How to Disable Auditing
If auditing is no longer required at some point, you can disable the auditing subsystem by running the bsmunconv command.
1. Become superuser or assume an equivalent role.
2. Bring the system into single-user mode.

# /etc/init 1
3. Run the script to disable auditing.
Change to the /etc/security directory, and execute the bsmunconv script there.

# cd /etc/security
# ./bsmunconv
4. Bring the system into multiuser mode.

# /etc/linit 6

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.

Device Allocation
Device allocation protects removable media from unauthorized use. You can require that a user allocate a device. You can deny a user permission to use a device. Such allocation measures can protect your site from loss of data, computer viruses, and other security breaches.
Components of the Device-Allocation Mechanism
The components of the device-allocation mechanism are as follows:
* The allocate, deallocate, dminfo, and list_devices commands.
* The /etc/security/device_allocate file.
* The /etc/security/device_maps file.
* A lock file in the /etc/security/dev directory for each allocatable device.
* Device-clean scripts for each allocatable device.
The device_allocate file, the device_maps file, and the lock files are local configuration files. These files are not administered as name service databases because tape drives, diskette drives, and printers connect to specific machines.
Using the Device Allocation Commands
This section describes some of the options to the allocate, deallocate, and list_devices commands that are for use by administrators. Only root or a role of equivalent power can access these options.

solaris bsm

/etc/security/device_maps file to determine the device names, device types, and device-special files that are associated with each allocatable device. Device maps are created when you set up device allocation.

A rudimentary device_maps file is created by bsmconv when the BSM is enabled. This initial device_maps file should be used only as a starting point. You can then augment and customize the device_maps file for your site.
Each device is represented by a one-line entry of the form:

Each device is represented by a one-line entry of the form:

device-name:device-type:device-list

solaris bsm

The device_allocate File
You can modify the device_allocate file to change devices from allocatable to nonallocatable, or to add new devices. A sample device_allocate file follows.

solaris bsm

You can decide to accept the default devices and their defined characteristics, as shown in the preceding sample device_allocate file. Whenever you add a device to any machine after the system is up and running, you must decide whether to make the new device allocatable.
After installation, you can modify the entries for devices in the device_allocate file. Any device that needs to be allocated before use must be defined in the device_allocate file on each machine. Currently, cartridge tape drives, diskette drives, CD-ROM devices, and audio chips are considered allocatable. These device types have device-clean scripts.
An entry in the device_allocate file does not mean that the device is allocatable, unless the entry specifically states that the device is allocatable. In the sample device_allocate file, note the asterisk (*) in the fifth field of the audio device entry. An asterisk in the fifth field indicates to the system that the device is not allocatable. That is, the system administrator does not require a user to allocate the device before it is used nor to deallocate it afterward.

In the device_allocate file, you represent each device by a one-line entry of the form:

device-name;device-type;reserved;reserved;alloc;device-clean
For example, the following line shows the entry for device name st0:

st0;st;;;;;/etc/security/lib/st_clean

The following table describes each field in the device_allocate file.

solris bsm

Device-Clean Scripts
The device-clean scripts address the security requirement that all usable data be purged from a physical device before reuse. By default, cartridge tape drives, diskette drives, CD-ROM devices, and audio devices require device-clean scripts, which are provided. This section describes what device-clean scripts do.
Object Reuse
Device allocation satisfies part of the object-reuse requirement. The device-clean scripts make sure that data that is left on a device by one user is cleared. The data is cleared before the device is allocatable by another user.
Device-Clean Script for Tapes
The st_clean device-clean script supports three tape devices. The supported tape devices are as follows:
* SCSI 1/4-inch tape
* Archive 1/4-inch tape
* Open-reel 1/2-inch tape

Device-Clean Scripts for Diskettes and CD-ROM Devices
The following table shows the device-clean scripts for diskettes and CD-ROM devices.

solaris bsm

Tags: vlan, vtp, router, wan, cisco, 802.1q

Comments are closed.