Chapter 25 Managing the BSM Service (Tasks)

This chapter presents procedures that are designed to help you set up and manage a Solaris environment that includes auditing. This chapter also includes instructions for administering the audit trail and for administering device allocation. This is a list of the task maps in this chapter.

• Managing BSM (Task Map)

• Configuring Audit Files (Task Map)

• Configuring the Audit Service (Task Map)

• Managing Audit Records (Task Map)

• Adding an Allocatable Device (Task Map)

Managing BSM (Task Map)

The following task map shows the major tasks that are required to administer the BSM services.

Configuring Audit Files

Before you enable auditing on your network, you may want to edit the audit configuration files. Many of the following procedures require that you restart the service or reboot the local system. You should make as many of these changes as possible before you start the service.

Configuring Audit Files (Task Map)

The following task map describes the tasks in this section.

How to Change Audit Flags

Audit flags are defined in the /etc/security/audit_control file. The audit flags select which classes of audit records are written to the audit log.

1. Become superuser or assume an equivalent role.

2. (Optional) Save a backup copy of the audit_control file.

   # cp /etc/security/audit_control /etc/security/audit_control.save

3. Add new entries to the audit_control file.

   Each entry has the following format:

   title:string

   title	Defines the type of line. Options are dir:, flags:, minfree:, or naflags:.
   string	Lists specific data that is associated with the line type

4. Instruct the audit daemon to read the new audit_control file.

   The audit daemon stores the information internally. To use the new information, either reboot the system or type the following command:

   # audit -s

Example—Changing Audit Trail File Locations

Lines that start with dir: define which audit file systems can be used to store audit trail files. In this example, two additional locations for audit trail files are defined.

# cat /etc/security/audit_control
dir:/etc/security/audit/host.1/files
dir:/etc/security/audit/host.2/files
dir:/var/audit
flags:
minfree:10
naflags:lo

Example—Changing Audit Flags for All Users

The flags line in the audit_control file defines which classes of events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the events in the lo class are audited for all users.

# cat /etc/security/audit_control
dir:/var/audit
flags:lo
minfree:10
naflags:lo

Example—Changing the Soft Limit for Warnings

The minfree line in the audit_control file defines the minimum free-space level for all audit file systems. In this example, the soft limit is set so that a warning is issued when only 10 percent of the file system is available.

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo

Example—Changing Auditing of Nonattributable Events

The naflags: line in the audit_control file defines which classes of nonattributable events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the na event class was added.

# cat /etc/security/audit_control
dir:/var/audit
flags:
minfree:10
naflags:lo,na

How to Change Users' Audit Characteristics

Definitions for each user can be stored in the /etc/security/audit_user file.

1. Become superuser or assume an equivalent role.

2. (Optional) Save a backup copy of the audit_user file.

   # cp /etc/security/audit_user /etc/security/audit_user.save

3. Add new entries to the audit_user file.

   Each entry has the following format:

   username:always:never
   

   username	Selects the name of the user to be audited
   always	Selects the list of audit classes that should always be audited
   never	Selects the list of audit classes that should never be audited

   You can specify multiple flags by separating the audit classes with commas. For more information about audit flags, see Audit Flags.

4. Make the new data available to the BSM service.

   To use the new data, either reboot the system, or have the user log out and back in again.

Example—Changing Auditing for One User

This example shows an entry that causes audit records to be generated any time that the user sue accesses any programs in the login class (lo).

# grep sue /etc/security/audit_user
sue:lo:

Example—Creating an Audit Admin Login

If all the audit partitions are full, then it could be impossible to log in to a host. If all logins are audited, then the fact that the audit partitions are full would prevent anyone from completing a login. To avoid this situation, you can set up a special login that is not audited. This new login would allow you to log in to the host even if the audit partitions are full. Then, you could fix the problem with the full partitions. In this example, the user auditadm is defined so that no auditing takes place.

# grep auditadm /etc/security/audit_user
auditadmin:no:yes

The user login that is selected to serve as the audit admin login might need to be monitored in another way.

How to Change Audit Classes

Audit classes are defined in the /etc/security/audit_class file.

1. Become superuser or assume an equivalent role.

2. (Optional) Save a backup copy of the audit_class file.

   # cp /etc/security/audit_class /etc/security/audit_class.save

3. Add new entries to the audit_class file.

   Each entry has the following format:

   0xnumber:name:description

   number	Defines the unique audit class mask
   name	Defines the two-letter name of the audit class
   description	Defines the descriptive name of the audit class

4. Make the new data available to the BSM service.

   To use the new data, either reboot the system, or type the following command:

   # auditconfig -conf

Example—Setting a New Audit Class

In step 3, add an entry that resembles the following to set a new audit class called de:

0x00010000:de:device allocation

How to Change Audit Events

Audit event definitions are stored in the /etc/security/audit_event file. A record is generated only after the event definition has been created and a user-level action generates the event.

1. Become superuser or assume an equivalent role.

2. (Optional) Save a backup copy of the audit_event file.

   # cp /etc/security/audit_event /etc/security/audit_event.save

3. Add new entries to the audit_event file.

   Each entry has the following format:

   number:name:description:classes
   

   number	Defines a unique audit event number, which must start after 32768.
   name	Defines the unique audit event name.
   description	Describes the audit event. Often includes the name of the man page for the audit event
   classes	Selects the audit classes that include this event.

4. Make the new data available to the BSM service.

   To use the new data, either reboot the system, or type the following command:

   # auditconfig -conf

Example—Adding a New Audit Event

This example shows an entry that defines a new audit event for a local application.

# grep localapp /etc/security/audit_event
32769:aue_localapp:localapp(1):ap

Configuring the Audit Service

This section covers the tasks that are required to configure and enable the audit service.

Configuring the Audit Service (Task Map)

The following task map describes the tasks that are required to configure auditing.

How to Create Partitions for Auditing

The following procedure shows how to create partitions for auditing, as well as the corresponding file systems and directories. Skip steps as necessary, depending on if you already have an empty partition, or if you have already mounted an empty file system.

1. Become superuser or assume an equivalent role.

2. Determine the amount of disk space that is required.

   Assign at least 200 Mbytes of disk space per host. However, the disk space requirements are based on how much auditing you perform. So, your requirements might be far greater than this figure. Remember to include a partition for a directory of last resort.

3. Create dedicated audit partitions, as needed.

   This step is most easily done during server installation. You can also create the partitions on disks that have not yet been mounted on the server. For complete instructions on how to create the partitions, see “Creating a UFS File System” in System Administration Guide: Basic Administration.

   newfs /dev/rdsk/cwtxdysz

   Where /dev/rdsk/cwtxdysz is the raw device name for the partition.

   If the local host is to be audited, create an audit directory of last resort for it as well.

4. Create mount points for each new partition.

   mkdir /var/audit/server-name.n

   Where server-name.n is the name of the server and a number that identifies each partition. The number is optional, but the number is useful when there are many audit directories.

5. Add entries to automatically mount the new partitions.

   Add a line to the /etc/vfstab file that resembles the following:

   /dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes

6. (Optional) Remove the minimum free space threshold on each partition.

   If you use the default configuration, a warning will be generated when the directory is 80 percent full, so there is no reason to reserve free space on the partition.

   tunefs -m 0 /var/audit/server-name.n

7. Mount the new audit partitions.

   mount /var/audit/server-name.n

8. Create audit directories on the new partitions.

   mkdir /var/audit/server-name.n/files

9. Correct the permissions on the mount points and new directories.

   chmod -R 750 /var/audit/server-name.n/files

10. (Optional) On a file server, define the file systems to be made available to other hosts.

    Often, disk farms are installed to store the audit records. If an audit directory is to be used by several systems, then the directory must be shared through the NFS service. Add a entry resembling the following for each directory to the /etc/dfs/dfstab file.

    share -F nfs /var/audit/server-name.n/files

11. (Optional) On a file server, restart the NFS service.

    If this command the first share command or set of share commands that you have initiated, it is probable that the NFS daemons are not running. The following commands kill the daemons and restart them. Refer to “Setting Up NFS Services” in System Administration Guide: Resource Management and Network Services for more information about the NFS service.

    # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

Example—Creating an Audit Directory of Last Resort

All systems that run the auditing service should have a local file system that can be used if no other file system is available. In this example, a file system is being added to a system named egret. Since this file system is only used locally, none of the steps for a file server are followed.

# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files

Example—Creating New Audit Partitions

In this example, a new file system is created on two new disks that are to be used by other systems in the network.

# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

How to Configure the audit_warn Alias

The audit_warn script generates mail to an alias called audit_warn. To send this mail to a valid email address, you can follow either of the following steps:

1. Become superuser or assume an equivalent role.

2. (Optional) Swap the audit_warn alias with another alias.

   One option is to edit the audit_warn script and replace audit_warn with another alias. After you swap audit_warn for root, the line that sends the email message would resemble the following:

   /usr/ucb/mail -s "$SUBJECT" root

   Ten lines in the script require this change.

3. (Optional) Redirect the audit_warn email to another alias.

   The other option is to redirect the email in the /etc/mail/aliases file. In this case, you would add an alias similar to the following to the local /etc/mail/aliases file or to the mail_aliases database in the name space. The new entry would resemble the following if the email were to be redirected to the root alias:

   audit_warn: root

How to Enable or Disable an Audit Policy

Audit policies determine the characteristics of the audit records for the local host. Audit policies are either enabled or disabled for a particular configuration. By default, all audit policies are disabled. You need to enable any audit policies that you want to use. For a description of each policy, see Audit Policies.

1. Become superuser or assume an equivalent role.

2. (Optional) Review the existing audit policies.

   Ensure that you are aware of all the policies that are being used before you change any. The following command lists the enabled policies:

   # auditconfig -lspolicy

3. Enable or disable the audit policy.

   auditconfig -setpolicy flagpolicyname

   flag	A + enables the policy. A – disables the policy
   policyname	Selects the policy to be enabled or disabled

   The policy is in effect until the next boot, or until the policy is modified by the auditconfig-setpolicy command.

Example—Setting the cnt Policy

The cnt policy can be set so that if the audit partitions become full, then processes are not blocked. The records are discarded when the partitions are full, but the system still functions even though the auditing process is not recording the events. The cnt policy should not be set if security is paramount, since unrecorded events can occur if the file system is full.

The following command enables the cnt policy:

# auditconfig -setpolicy +cnt

For a secure site, you should enable the cnt policy in an appropriate startup file.

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/telinit 1

   See the telinit(1M) man page for more information.

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 BSM after a reboot. See the bsmconv(1M) man page.

   # cd /etc/security # ./bsmconv

4. Bring the system into multiuser mode.

   # /etc/telinit 6

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

   ---

   Note –

   The bsmconv script adds a line to the /etc/system file that prevents users from aborting the system with the Stop-A keyboard sequence. To retain the ability to abort the system with the Stop-A keyboard sequence, you must comment out the line in the /etc/system file that reads: set abort_enable=0.

   ---

How to Disable Auditing

If BSM is no longer required at some point, you can disable it by running the bsmunconv command. See the bsmconv(1M) man page.

1. Become superuser or assume an equivalent role.

2. Bring the system into single-user mode.

   # /etc/telinit 1

   See the telinit(1M) man page for more information.

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/telinit 6

   ---

   Note –

   The bsmunconv script removes the line in the /etc/system file that allows users to abort the system with the Stop-A keyboard sequence. If you want to continue to prevent users from aborting the system with the Stop-A keyboard sequence after you run the bsmunconv script, you must reenter into the /etc/system file the line that reads: set abort_enable=0.

   ---

Managing Audit Records

Managing the audit trail enables you to monitor the actions of users on your network. Auditing can generate large amounts of data. The following tasks show you how to work with all this data.

Managing Audit Records (Task Map)

The following task map describes the tasks in this section.

How to Merge Audit Records

This task shows you how to merge all audit files in all the audit directories. Follow these steps when you want to analyze the contents of the audit trail.

1. Become superuser or assume an equivalent role.

2. Change directories to the primary audit directory.

   # cd /etc/security/audit/server-name.1/files

   Moving to this directory places the merged file in this protected directory.

3. Merge the audit records.

   # auditreduce > merged.log

   All directories that are listed in the dir: lines of the audit_control file on server-name are merged and placed in the file called merged.log.

Example—Displaying the Entire Audit Trail

To display the entire audit trail at once, pipe the output of the auditreduce command into the praudit command.

# auditreduce | praudit

Example—Printing the Entire Audit Trail

With a pipe to the lp command, the output goes to the printer.

# auditreduce | praudit | lp

Example—Combining and Reducing Audit Files

Use auditreduce with the -O option to combine several audit files into one file and to save them in a specified output file. auditreduce can do this type of combination and deletion automatically (see the -C and -D options in the auditreduce(1M) man page). However, it is often easier to select the files manually (perhaps with the find command) and use auditreduce to combine just the named set of files.

When used in this way, auditreduce merges all the records from its input files into a single output file. The input files should then be deleted. In addition, the output file should be kept in a directory that is named /etc/security/audit/server-name/files so that auditreduce can find it.

# auditreduce -O combined-filename

The auditreduce command can also reduce the number of records in its output file by eliminating the less interesting records as it combines the input files. For example, you might use auditreduce to retain only the login and logout records in audit files that are over a month old. If you need to retrieve the complete audit trail, you could recover it from backup tapes.

# auditreduce -O daily.summary -b 19990413 -c lo; compress *daily.summary
# mv *daily.summary /etc/security/summary.dir

Example—Displaying User Activity From a Selected Date

In the following example, the system administrator checks to see when user tamiko logged in and logged out on April 13, 1999, by requesting the lo event class. The short-form date is in the form yymmdd. The long form is described in the auditreduce(1M) man page.

# auditreduce -d 990413 -u tamiko -c lo | praudit

Example—Copying Selected Records to a Single File

In this example, login and logout messages for a particular day are selected from the audit trail and merged into a target file. The target file is written in a directory other than the normal audit root directory.

# auditreduce -c lo -d 990413 -O /usr/audit_summary/logins 

The -O option creates an audit file with 14-character timestamps for both the start-time and the end-time, with the suffix logins:

/usr/audit_summary/19990413000000.19990413235959.logins

Example—Cleaning Up a not_terminated Audit File

Occasionally, an audit daemon dies while its audit file is still open, or a server becomes inaccessible and forces the machine to switch to a new server. In such instances, an audit file remains with the string not_terminated as the end-time, even though the file is no longer used for audit records. When you find such a file, you can manually verify that the file is no longer in use and clean it up by specifying the name of the file with the correct options.

# audit -s
19990414121112.not_terminated.egret
# auditreduce -O egret 19990413120429.not_terminated.egret

The audit command checks the name of the current audit file. The auditreduce command creates a new audit file with the correct name and correct timestamps, with the correct suffix (egret), and copies all the records into it.

How to Display Audit Record Formats

The following command displays the formats of all audit event records. This command operates on records in the audit_class, audit_event, and audit_record_attr files.

# bsmrecord -a

Example—Displaying the Format of an Audit Record

In this example, the format of the audit record with an ID of 6152 is displayed.

# bsmrecord -i 6152
# login: terminal login
program  /usr/sbin/login  see login(1)
event ID 6152             AUE_login
class  lo  (0x00001000)
header-token
subject-token
text-token   error message
exit-token
#

How to Prevent Audit Trail Overflow

If your security policy requires that all audit data be saved, do the following:

1. Set up a schedule to regularly archive audit files and to delete the archived audit files from the audit file system.

2. Manually archive audit files by backing them up on tape or by moving them to an archive file system.

3. Store context-sensitive information that will be needed to interpret audit records, along with the audit trail.

4. Keep records of which audit files are moved offline.

5. Store the archived tapes appropriately.

6. Reduce the volume of audit data that you store by creating summary files.

   You can extract summary files from the audit trail by using options to auditreduce so that the summary files contain only records for certain specified types of audit events. For examples, see Example—Combining and Reducing Audit Files and Example—Copying Selected Records to a Single File.

Managing Device Allocation

You can use device allocation to decrease the security risk that is associated with various removable media.

Adding an Allocatable Device (Task Map)

The following task map describes the major steps that are required to define a new allocatable device.

How to Set Up Lock Files for an Allocatable Device

The lock files are zero-length files that are created in the /etc/security/dev directory. One file is created for each allocatable device. If no lock file exists for a device, the device cannot be allocated, so no one can access the device.

1. Become superuser or assume an equivalent role.

2. Obtain the device name for the device from its entry in the device_maps file by using the dminfo command.

   See The device_maps File and the dminfo(1M) and device_maps(4) man pages. For example, the device name for device type st is st0. In the next step, you will use the device name as the name of the lock file.

3. Create an empty lock file for the device by using the touch command.

   Use the device name for the file name in place of device-name.

   # cd /etc/security/dev # touch device-name # chmod 600 device-name # chown bin device-name # chgrp bin device-name

How to Change Which Devices Can Be Allocated

This procedure defines which devices can be used with the device allocation mechanism.

1. Become superuser or assume an equivalent role.

2. Determine which devices are listed in the /etc/security/device_allocate file.

3. Decide if there are devices that are not in the device_allocate file, yet should be made allocatable.

4. Edit the device_allocate file and add the new device.

   Each entry should use the following format:

   device-name;device-type;;;;program

   device-name	Specifies the name of the device
   device-type	Specifies the device type
   program	Specifies the purge program to be run

How to Allocate a Device

1. Become superuser or assume an equivalent role.

2. Use the allocate command with a device that is specified by device name.

sar1% allocate st0

You can also allocate a device by device type by using the -g option to the allocate command.

If the command cannot allocate the device, an error message is displayed in the console window. For a list of allocation error messages, see the allocate(1) man page.

Example—Allocating a Printer

sarl% allocate /dev/lp/chestnut

Only the user who ran the allocate command can use the printer.

How to Deallocate a Device

Deallocate a device by using the deallocate command followed by the device file name.

sar1% deallocate st0

Deallocation enables other users to allocate and use the device when you are finished.

Example—Deallocating a Printer

To deallocate a printer that is named chestnut, type the following command:

# deallocate /dev/lp/chestnut

Example—Forcing a Deallocation

Devices that a user has allocated are not automatically deallocated when the process terminates or when this user logs out. You most commonly need to use the following form of the deallocate command when a user forgets to deallocate a specific device. Then you force its deallocation, so that others users can allocate it.

# deallocate -F st0

Example—Deallocating All Devices

You can deallocate all devices only at system initialization time.

# deallocate -I