Chapter 22 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. The following is a list of the task maps in this chapter.

• Managing the BSM Service (Task Map)

• Configuring Audit Files (Task Map)

• Configuring the Auditing Service (Task Map)

• Managing Audit Records (Task Map)

• Adding an Allocatable Device (Task Map)

For an overview of auditing, see Chapter 20, BSM (Overview). For planning suggestions, see Chapter 21, Audit Planning.

Managing the BSM Service (Task Map)

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

Configuring Audit Files (Task Map)

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

The following task map describes the tasks in this section.

How to Select 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 the Location of the Audit Trail File

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 are stored in the /etc/security/audit_user file. These definitions are exceptions to the flags in the audit_control 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 Classes and Their Audit Flags.

4. Make the new data available to the auditing daemon.

   To use the new data, you can reboot the system. You can also have the user log out and then log 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 and logins are audited, then users might not be able to log in to a host. To avoid this situation, you can set up a special account that is not audited. The special account could log in to the host even when the audit partitions are full, and fix the problem with the full partitions. In this example, the account auditadm is defined so that no auditing takes place.

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

The user who is selected to use the audit admin account might need to be monitored in another way.

How to Add 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

   0x

   Identifies number as hexadecimal.

   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 this example, add an entry to the audit_class file that resembles the following entry. The entry creates a new audit class that is called ta.

0x01000000:ta:test application

How to Change an Audit Event's Class Membership

Event-class mappings are defined in the /etc/security/audit_event file.

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

3. Change the class to which particular events belong by changing the flag of the events.

   Each entry has the following format:

   number:event:program:flag

   number

   Defines the audit event ID.

   event

   Defines the name of the audit event.

   program

   Defines the system call or user-level program executable that triggers the creation of an audit record.

   flag

   Defines the two-letter 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 commands:

   # auditconfig -conf # audit -s

Example—Creating a Site-Specific Audit Event Mapping

In this example, you define a new class, and then add events to that class. To use the mapping, put the new class in the audit_control file, then reboot the system.

1. In the audit_class file, define a site-specific class to collect just those audit events that you want to monitor.

   0x00000800:sc:site class

2. In the audit_event file, change a set of audit events to the new class.

   26:AUE_SETGROUPS:setgroups(2):sc 27:AUE_SETPGRP:setpgrp(2):sc 40:AUE_SETREUID:setreuid(2):sc 41:AUE_SETREGID:setregid(2):sc 214:AUE_SETEGID:setegid(2):sc 215:AUE_SETEUID:seteuid(2):sc

3. Use the new flag in the audit_control file. The following entry audits logins, and audits all successful invocations of the events in the sc class.

   flags:lo,+sc

4. To ensure that the new configuration audits all processes, reboot the system. Or, you can use the following set of commands to ensure that each user who uses the machine is correctly audited. auid is the user ID.

   # auditconfig -conf # audit -s # setumask auid lo,+sc

How to Add Audit Events

Audit event definitions are stored in the /etc/security/audit_event file.

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

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

   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
32768:AUE_localapp:localapp(1):ta

Configuring the Auditing Service (Task Map)

This section covers the tasks that are required to configure and enable the auditing service. The following task map describes the tasks that are required to configure the auditing service.

How to Create Partitions for Auditing

The following procedure shows how to create partitions for audit files, 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 the local host 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 plus 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 is generated when the directory is 80 percent full. The warning removes the 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 an entry that resembles 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 is the first share command or set of share commands that you have initiated, the NFS daemons are probably not running. The following commands kill the daemons and restart the daemons. 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 subsystem 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 that is 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 that is called audit_warn. To send this mail to a valid email address, you can follow either of the following options:

1. Become superuser or assume an equivalent role.

2. Configure the audit_warn mail alias.

   OPTION 1 –

   Replace the audit_warn alias with another mail account in the audit_warn script.

   After you replace audit_warn with the root account, the line that sends the email message would resemble the following:

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

   Ten lines in the audit_warn script require this change.

   OPTION 2 –

   Redirect the audit_warn email to another mail account.

   In this case, you would add the audit_warn alias to the appropriate mail aliases file. You could add the alias 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 root mail account was made a member of the audit_warn 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. 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.

You can inspect, enable, or disable the current audit policy with the auditon() system call at the program level. Or, to do the same task, you can run the auditconfig command. You can also modify the policy options to the auditconfig command in the audit_startup script to make more permanent audit policy changes.

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 policies. The following command lists the enabled policies:

   # auditconfig -lspolicy

3. Enable or disable the audit policy.

   # auditconfig -setpolicy flagpolicyname

   flag

   A flag value of + enables the policy. A flag value of - disables the policy.

   policyname

   Selects the policy to be enabled or to be 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. The cnt policy keeps a count of the number of discarded audit records. 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

To maintain the policy across reboots, you should place the auditconfig -setpolicy +cnt command in the audit_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 auditing 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.

How to Disable Auditing

If auditing is no longer required at some point, you can disable the auditing subsystem 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

Managing Audit Records (Task Map)

By managing the audit trail, you can 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.

The following task map describes the tasks in this section.

How to Display Audit Record Formats

The bsmrecord command displays the audit id, audit class, selection mask, and record format of an audit event. The command operates on records in the audit_class and audit_event files.

The -a option in the following command lists all audit event record formats. The -h option puts the list in HTML format. The resulting file can be displayed in a browser.

Use the bsmrecord command to put the format of all audit event records in an HTML file.

% bsmrecord -a -h > audit.events.html

You can display the *html file in a browser. Use the browser's Find tool to find specific records.

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

Example—Displaying the Audit Record Formats of a Program

In this example, the format of all audit records that are generated by the login program are displayed.

% bsmrecord -p login

terminal login
  program     /usr/sbin/login      see login(1)
  event ID    6152                 AUE_login
  class       lo                   (0x00001000)
      header
      subject
      text                         error message or "successful login"
      return

login: logout
  program     /usr/sbin/login      see login(1)
  event ID    6153                 AUE_logout
  class       lo                   (0x00001000)
      header
      subject
      text                         "logout" username
      return

rlogin
  program     /usr/sbin/login      see login(1) - rlogin
  event ID    6155                 AUE_rlogin
  class       lo                   (0x00001000)
      header
      subject
      text                         success/fail message
      return

telnet login
  program     /usr/sbin/login      see login(1) - telnet
  event ID    6154                 AUE_telnet
  class       lo                   (0x00001000)
      header
      subject
      text                         success/fail message
      return

Example—Displaying the Audit Record Formats of an Audit Class

In this example, the format of all audit records in the fd class are displayed.

% bsmrecord -c fd

ftruncate
    Not used.

truncate
    Not used.

unlink
  system call unlink               see unlink(2)
  event ID    6                    AUE_UNLINK
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      return

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

   The merged file is placed in the /etc/security/audit/server-name.1/files directory. This directory is a 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. The merged records are then placed in the merged.log file in the current directory.

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 the auditreduce command with the -O option to combine several audit files into one file and to save the files 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, you can select the files manually to good effect. Use the find command, then use auditreduce to combine just the named set of files.

When used in this way, the auditreduce command 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 the output file.

# auditreduce -O combined-filename

The auditreduce command can also reduce the number of records in its output file. The command can eliminate the less interesting records as it combines the input files. For example, you might use the auditreduce command 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 the trail 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. The administrator requests 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. The messages are 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. You can clean up the open file 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. The correct name includes the correct suffix (egret). The auditreduce then copies all the records into the file.

How to Display Audit Records

1. Become superuser or assume an equivalent role.

2. Change directories to an audit files directory, such as /usr/audit_summary/logins.

   # cd /usr/audit_summary/logins

3. Read a file by using the praudit command.

   # praudit 19990413000000.19990413235959.logins | more

Example—Putting Audit Records in XML Format

In this example, the audit records are converted to XML format. XML format can be displayed in a browser. The format can also be used to create a report.

# praudit -x 19990413000000.19990413235959.logins > 19990413.logins.xml

The *xml file can be displayed in a browser. The contents of the file can be operated on by a script to extract the relevant information.

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. Set up a schedule to delete the archived audit files from the audit file system.

2. Manually archive audit files by backing up the files on tape. You can also move the files to an archive file system.

3. Store context-sensitive information that is necessary 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 the auditreduce command. The summary files then 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 (Tasks)

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

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

sarl% allocate /dev/lp/chestnut

How to Deallocate a Device

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

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

   sar1% deallocate st0

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. The following command deallocates the device so that others users can allocate the device.

# deallocate -F st0

Example—Deallocating All Devices

You can deallocate all devices only at system initialization time.

# deallocate -I