Audit of Solaris BSM – An Overview

Basic Security Module or BSM is the audit tool used by Solaris Operating System. The BSM files are located in the /etc/security directory. To enable the BSM, the administrator has to run the bsmconv script. This script creates a number of files in the /etc/security directory. In this article we shall discuss two important files that are created viz. Audit Control File and Audit User File

Audit_Control File

The audit_control file is the primary configuration file for BSM

Consider a sample of this file:

# more /etc/security/audit_control
dir: /var/audit
flags: pc,ad,ex
minfree: 20
naflags: lo

The first entry specifies ‘where’ the audit files are to be written. The logs are not in ASCII format, they are in binary format. Using the praudit command, these logs can be converted into human readable form.

The second entry specifies ‘what’ events are to be audited. The last entry specifies what are not to be audited. An event is specified using a flag and there are a lot of flags that can be turned on or off.  For example:

  • no = no_class
  • fr = file_read
  • fw = file_write
  • lo = login_logout
  • ad = administrative
  • pc = process control
  • ex = execution

The third entry specifies ‘how much disk space’ should be available for the auditing to continue. This is necessary to monitor the amount of disc space that is consumed by auditing. In the given case, when the audit partition goes above 80% full, the auditing subsystem starts sending the administrator annoying warning messages (via the /etc/security/audit_warn script).

Audit_User File

This is an access restricted ASCII system file that stores per-user, auditing pre-selection data In other words, for a particular user, it specifies what flags are to be audited, what are not.

Consider a sample of this file:

# more /etc/security/audit_user

fred:lo,fw:fr

This means that for the user ‘fred’ (First paramenter) the following events are audited (Second parameter): login_logout and file_write. The third parameter specifies the event classes that are not to be audited; here file_read.

Auditing is relatively simple to start, but if left unchecked, the volume of disc space consumed by the audit trail could be phenomenon. Of course, the simple solution is to ensure that all those events required to reconstruct what has been happening on the system are logged while regular and uninteresting events are dropped.

The real challenge with BSM is tuning the level of auditing that is required. Once this is done, BSM serves as an excellent audit tool.

Comments are closed.