Chapter 2 Auditing Setup

The focus of this chapter is on setting up auditing for a network of Trusted Solaris systems. It also describes how to set up auditing for a non-networked Trusted Solaris system.

• Planning Auditing at Your Site

• Planning the Rollout

• Rolling Out Auditing at Your Site

• Audit Shutdown and Startup (Tasks)

• Basic Audit Setup (Tasks)

• Advanced Audit Setup (Tasks)

• Dynamic Auditing (Tasks)

Planning Auditing at Your Site

When the system administrator and security administrator configure the first system for the Trusted Solaris operating environment, auditing is enabled and a limited number of audit records are collected to a default audit location, system_name:/var/audit. The security administrator needs to plan what to audit and whether to customize site-specific event-to-class mappings. The system administrator plans disk space (local and remote) for the audit files, an audit administration server, and the order of installation.

Planning auditing for a non-networked system is a bit simpler. For a single system, customizing event-to-class mappings may not be worth the time. Your most important task is to ensure that auditing does not slow down your work. Planning the size and locations of auditing partitions can prevent work slowdown, and a regular maintenance schedule can automatically back up and free up the audit partition for more audit records.

Planning What to Audit

Trusted Solaris auditing collects user actions and non-attributable (in the class na, non-attribute) events into audit classes. It is these audit classes, each of which holds a number of events, that are audited for success, for failure, or for both.

Before configuring auditing, understand the audit flags and the types of events they flag. Develop a philosophy of auditing for your organization that is based on the amount of security your site requires and the types of users you administer.

Unless the process audit preselection mask is modified dynamically, the audit characteristics in place when a user logs in are inherited by all processes during the login session, and, unless the databases are modified, the process preselection mask applies in all subsequent login sessions.

See Audit Events Listed by Audit Class for a list of provided audit classes. Each audit class is listed in its own table, where each audit event's corresponding system call or user command points to its audit record format.

The security administrator plans what to audit based on the site security policy. You can configure a system-wide setup and user exceptions/additions.

1. Decide if non-attributable events should be audited.

   The audit flag na represents the non-attributable class of events. For example, accessing the PROM, booting, and remote mounting are non-attributable events. See Events in Audit Class na for a list of the events in the default non-attribute class.

   When you audit a class, you audit all events in that class. If you want to customize the non-attributable class, see Planning a Site-Specific Event-to-Class Mapping.

   To audit non-attributable events, you will enter the na flag on the naflags: line of the audit_control file.

2. Decide whether to audit them for success, for failure, or for both.

   To audit non-attributable events for success, the naflags: line of the audit_control file would look like:

   naflags:+na

   To audit non-attributable events for failure:

   naflags:-na

   To audit non-attributable events for both:

   naflags:na

3. Decide if all events will be audited.

   ---

   Note –

   The class all includes all auditable events in the Trusted Solaris software environment. While unusual circumstances may dictate use of this class, typically you would avoid auditing all events.

   ---

4. If you are not going to audit all events, repeat Step 1 and Step 2 for the other audit classes as you did for the class na.

   You enter your auditing decisions in the audit_control file when establishing auditing on the first system. The na flag goes on the naflags: line. All other class flags go on the the flags: line of the audit_control file.

5. Determine if there are particular users or roles that should be audited slightly differently than the system-wide setup.

   You will enter user exceptions to the system setup in the audit_user file. In the Trusted Solaris 8 4/01 release, the security administrator does not edit the audit_user file directly. The Audit tab on a user's account in the Solaris Management Console (SMC) handles each user's audit flags as part of the account. The SMC distributes the user information using the site's name service.

6. Be consistent.

   All hosts in a Trusted Solaris network should have identical naflags: entries in their audit_control files.

   All hosts in a Trusted Solaris network should have identical flags: entries in their audit_control files.

   All hosts in a Trusted Solaris network should have identical audit_user files. The Solaris Management Console will distribute user audit information using the site's name service.

Considerations When Planning What to Audit

What is audited at your site is based on your site policy and the costs of auditing (time, efficiency, disk space), as discussed in Controlling Audit Costs . The following are factors to consider when using auditing as it is implemented in the Trusted Solaris environment.

• Every audit record stands alone, so records can quickly fill up disk space.

  Therefore, you might want to start with a small amount of auditing and see how the audit partitions fill. You can then make more educated estimates of disk requirements and an audit archiving schedule. You can refine audit classes as you get an estimate of the size of the audit trail.

• The number of events in an audit class does not necessarily correlate to how many records are generated.

  For example, the file read class contains about the same number of events as the login or logout class. Enabling the file read class for success is likely to generate many more records than enabling the login or logout class for success.

• Auditing for failure locates abnormal events; auditing for success monitors system use.

  If site policy requires monitoring of system use, you will want to set aside more space for the audit trail than if you are auditing for abnormal events.

• Auditing for failure may generate many fewer records than auditing for success.

  For example, auditing for failure of file read events in a Trusted Solaris system of sophisticated users can generate many fewer records than turning on the file read class for success.

• Configuring the audit classes differently, or setting up new audit classes for audit events can more efficiently satisfy your site requirements. By excluding audit events that site policy does not require to be audited, the audit trail is smaller.

  For example, you may want to create a class de for devices. When configuring devices, audit the class for success to generate a record of what devices have been set up and tested. When all devices have been configured, you may want to audit the class for failure.

• Configuring some classes to be audited intermittently may satisfy your site requirements.

  For example, you may want to audit the audit class you created, de, intermittently. A cron job, or the command auditconfig(1M), enable you to turn auditing on and off for particular classes and set other audit flags dynamically.

Planning a Site-Specific Event-to-Class Mapping

Optional: Skip this section if you are using the default event-to-class mappings provided in the Trusted Solaris environment. Do not skip this section if you have decided to rearrange what events are assigned to what classes, or to create new classes or new events.

Trusted Solaris software handles up to 32 audit classes, including the class all. Your site may add classes until the total number is 32.

The security administrator plans site-specific mappings. To plan site-specific mappings:

1. Decide what classes are needed.

2. Decide what events belong in what classes.

   1. Decide what events should be copied to another class or classes.

      An audit event can belong to more than one class. For example, the audit event AUE_RENAME belongs to the classes file create and file delete in the default event-to-class mapping.

   2. Decide what events should be moved to another class or classes.

   3. Decide what events should be added to a class or classes.

3. For each class, decide whether to audit it for success, for failure, or for both.

   When new software programs include audit events not provided by Trusted Solaris software, add the events to existing classes or create a new classes for the new events.

Considerations When Changing Event-to-Class Mappings

The following are factors to consider when changing the contents of default audit classes and creating new ones in the Trusted Solaris environment.

• This document, Trusted Solaris Audit Administration, reports the default auditing configuration.

  Document your site's modifications to the auditing defaults, and make the document available to the administrators handling audit administration.

• If you are networked, you must change the auditing configuration files on all the systems when you change the files on one system.

  A network of Trusted Solaris systems should behave like one system. When auditing is enabled, it should be enabled on every host, and every host should be audited for the same classes, with the same defaults, the same user exceptions, and the same event-to-class mappings as every other Trusted Solaris host in the network.

Planning Space on a Non-Networked Systems

Storing audit records on a non-networked system involves setting up at least two local partitions dedicated to audit records, one primary and one backup, and planning a maintenance schedule.

On a non-networked system, plan the size of a disk partition to hold audit records. For efficiency, it is best to place the audit records on a separate disk. For safety, you may want to create two audit partitions on that disk, one as the primary storage area and the other as a backup when the first partition gets full. Set filesystem security attributes to set on the audit directory to prevent snooping on the audit trail.

1. Estimate the volume of auditing between audit record backups.

   Balance your security needs against the availability of disk space for audit trail storage.

   A rule of thumb is to assign 200 MB of space per system. However, the disk space requirements for the system are based on how much auditing you perform and may be far greater than this figure.

   Controlling Audit Costs and Auditing Efficiently provide guidance on how to reduce storage requirements.

2. Decide at what point the audit file system sends a warning that it is filling up.

   You will specify what is called the minfree limit for audit partitions in the audit_control file. This is the percentage of disk space remaining when the audit administrator is sent an email message (by the audit_warn alias) that the disk is getting full. The default is to send the warning when there is 20% disk space remaining. This percentage is tunable.

Planning Space on a Network of Hosts

Storing audit records for a network of hosts involves setting up a local (backup) partition dedicated to audit records, plus a network of audit servers with partitions for remote (primary) audit storage, and plus an audit administration server from which the entire audit trail can be monitored. The audit trail is every audit file (audit files hold audit records generated on a system) created by every system on the network.

A networked system should include audit servers to store audit files for users' systems, an audit administration server for central audit analysis and backup, and a local audit partition on every host. You may want to set filesystem security attributes on the directories and mount points to prevent snooping on the audit trail. Create a worksheet to record your auditing plan, or use another mechanism that helps you track the auditing network that you set up.

1. Determine how much auditing your site needs to do.

   Balance your site's security needs against the availability of disk space for audit trail storage.

   A rule of thumb is to assign 200 MB of space for each host that will be on the distributed system, but remember that the disk space requirements at your site is based on how much auditing you perform and may be far greater than this figure per host. If you are able to dedicate a local and a remote disk for auditing, one way to set up audit partitions is to divide each disk into two partitions.

   Controlling Audit Costs and Auditing Efficiently provide guidance on how to reduce storage requirements while still maintaining site security.

2. Decide at what point each audit file system for the system sends a warning that it is filling up.

   You will specify what is called the minfree limit for audit partitions in the audit_control file. This is the percentage of disk space remaining when the audit administrator is sent an email message (by the audit_warn alias) that the disk is getting full. The default is to send the warning when there is 20% disk space remaining. This percentage is tunable.

3. Determine which hosts will be audit servers.

   The install team will install these systems before installing the audit client systems.

4. Plan a local audit partition for each system.

   The local partition provides a backup in cases where the audit server's partitions are full or when the network is unreachable.

5. Determine which clients will use which audit file systems on which audit server.

   Lay out the auditing network. The following figure shows an audit server, egret, with file systems /etc/security/audit/egret[.n]/files available to store remote hosts' audit records.

   Figure 2–1 Audit Server egret's Audit File Systems

   
   

6. Follow the naming conventions for audit file systems.

   As illustrated in the figure, the convention for naming the audit file systems on a system is:

   /etc/security/audit/system_name/files
   /etc/security/audit/system_name.1/files
   /etc/security/audit/system_name.2/files
   /etc/security/audit/system_name.3/files …
   

   For an explanation of the naming scheme, see Audit Storage.

Planning the Rollout

Rolling out the auditing plan to the systems is a job coordinated by the system administrator, who sets up the disks and the network of audit storage, and the security administrator, who decides what is to be audited and enters the information in the audit configuration files. Together, you want to set up an audited network of systems where:

• From one host, the audit analyst is able to read every audit file on every host in the network, and the system operator is able to back up every audit file on every host on the network.

  How: Create an administration server, and mount all audit directories on the server.

• The audit trail is not available for snooping.

  How: Protect audit directories with appropriate discretionary access controls and mandatory access controls. You may want to audit directory access.

• Each host in a Trusted Solaris distributed system is writing records to the audit trail from the first time it is in multiuser mode, and thereafter.

  How: Create audit servers before you create user systems. On all systems, create a dedicated audit partition during installation.

• Every system is audited identically.

  How: Create a central location for all audit configuration files that are not controlled by the Solaris Management Console: audit_event, audit_class, audit_control, audit_startup, and audit_warn. The examples use the directory /export/home/tmp on the NIS+ master. Copy these files to a tape or diskette that is copied to every system.

• When an end user's system is configured, it is able to immediately send its audit records to an audit server.

  How: Create the audit servers and configure them for receiving audit records before the end user systems are set up. Create a procedure to copy the system-wide audit configuration files to each host and to modify the audit_control file for the audit storage locations for that host.

• End user's systems are not slowed down by writing audit records.

  How: Regular archiving of the audit trail frees up audit server disk space. Placing the local audit storage on a separate or little-used disk will enable the end user to work quickly when audit records are stored locally.

Rolling Out Auditing at Your Site

To roll out auditing, the system administrator sets up the audit administration server, the audit file servers, the local audit partitions, and what usernames are warned of audit trouble. The security administrator edits the audit_control(4) file on the NIS+ root master, and edits other audit configuration files before copying them to a central directory for distribution by tape or floppy. The audit configuration files are copied from the tape to each system as it is configured by the install team. The security administrator edits the dir: lines in the audit_control file on each system before the system is rebooted.

Administrators should understand that the Trusted Solaris environment only records the security-relevant events that it is configured to record (that is, by preselection). Therefore any subsequent audit can only consider the events recorded. If auditing is not configured to record the security-relevant events for the particular system environment in which it operates, it will not be possible to audit. This may mean that attempts to breach the security of the system go undetected, or that the administrator is unable to detect the user responsible for an attempted breach of security. Administrators should regularly analyze audit trails to check for breaches of security.

System Administrator's Audit Setup Tasks

Security Administrator's Audit Setup Tasks - Basic

Security Administrator's Audit Setup Tasks - Advanced

Audit Shutdown and Startup (Tasks)

The following procedures describe how to enable and disable auditing for one or more systems. The commands should be run only on a diskfull computer, and never on a diskless client.

Auditing tasks require commands and actions that are limited to particular roles and particular labels. Read each task for the administrative role that can perform it, and the label required. See To Execute Commands that Require Privilege for how to assume a role and open a privileged shell.

To Disable Auditing

1. As role secadmin, at label admin_low, open the script /etc/init.d/audit using the Admin Editor.

   ---

   Note –

   This should be done only if auditing is not a site security requirement, or in cases of audit file overflow. The security administrator is responsible.

   ---

2. Comment out the start script:

   …
   # Start the audit daemon
   #  if [ -f /etc/security/audit_startup ] ; then
   #  echo ”starting audit daemon”
   #  /etc/security/audit_startup
   #  /usr/sbin/auditd &
   #  fi
   …

3. Write and quit the file.

4. Open the script /etc/init.d/drvconfig using the Admin Editor.

5. Add the following lines to the end of the file:

   # Disable auditing
   #
   /usr/bin/adb -wk /dev/ksyms /dev/mem > /dev/null <<end
   audit_active/W 0
   end
   

6. Prevent spurious messages about the audit daemon at shutdown by commenting out the stop script in /etc/init.d/audit:

   …
   # Stop the audit daemon
   
   #       if [ -f /etc/security/audit_startup ] ; then
   #               /usr/sbin/audit -t
   #       fi

7. Write and quit the file.

8. For the changes to take effect, reboot.

   ---

   Note –

   A user or role requires authorization to shut down the computer.

   ---

   1. Choose Shut Down from the TP (Trusted Path) menu and confirm the shutdown.

   2. Enter boot at the ok prompt or b at the > prompt:

      Type help for more information <#2> ok boot Type b (boot), c (continue), or n (new command mode) > b

To Enable Auditing

By default, auditing is enabled. If you have disabled auditing, enable it by reversing the above procedure.

1. As role secadmin, at label admin_low, open the script /etc/init.d/audit using the Admin Editor.

2. Remove the comments from the audit start script:

   …
   # Start the audit daemon
   	if [ -f /etc/security/audit_startup ] ; then
   			echo ”starting audit daemon”
   			/etc/security/audit_startup
   			/usr/sbin/auditd &
   	fi
   …
   

3. Write and quit the file.

4. Enable the audit daemon to exit gracefully at shutdown by removing the comments in the stop script in /etc/init.d/audit:

   …
   # Stop the audit daemon
   	if [ -f /etc/security/audit_startup ] ; then
   		/usr/sbin/audit -t
   		fi

5. Write and quit the file.

6. Open the script /etc/init.d/drvconfig using the Admin Editor.

7. Comment out the Disable auditing lines:

   # Disable auditing
   #
   # /usr/bin/adb -wk /dev/ksyms /dev/mem > /dev/null <<end
   # audit_active/W 0
   # end

8. Write and quit the file.

9. For the changes to take effect, reboot using the Shut Down menu item from the TP (Trusted Path) menu.

Basic Audit Setup (Tasks)

The following procedures describe how to set up auditing for one or more systems.

To Create Dedicated Audit Partitions

During installation, the install team creates dedicated audit partition(s) when formatting the disks.

Use the naming convention /etc/security/audit/sytem_name(.n)

A diskfull computer should have at least one local audit directory, which it can use as a directory of last resort, if unable to communicate with the audit server.

See Audit Storage for an explanation of the naming convention.

On an audit file server, most partitions hold audit files, as is shown in the following example of the egret audit file server:

Another disk holds egret's / (root) and /swap partitions.

On a diskfull computer, including the audit administration server, at least one partition should be dedicated to local audit files, as is shown in the following example of the system willet:

Hints

A rule of thumb is to assign 200 MB of space for each system. However, the disk space requirements at your site will be based on how much auditing you perform and may be far greater than this figure.

Fewer and large partitions are more efficient than more and smaller ones.

To add a disk to hold audit partitions after installing the system, see the Solaris 8 System Administration Guide, Volume II. To protect the disks with Trusted Solaris security attributes, see Trusted Solaris Administrator's Procedures.

To Execute Commands that Require Privilege

Most commands for setting up auditing require the use of a profile shell, where commands can run with privilege. Auditing also requires the use of actions in the System_Admin folder and the Solaris Management Console action in the Application Manager.

1. Log in to the computer as yourself.

   1. Enter your user name and press the Return key.

      If the system is protected against anyone logging in, the Enable Logins dialog is displayed.

   2. If you are authorized to enable logins, click the Yes button after Login:.

      If you are not authorized to enable logins, ask the administrator to enable logins.

   3. Enter your password and click OK.

      You are presented with the message of the day and a label builder screen. In a single-label system, the screen describes your session label. In a multilabel system, it presents you with a label builder to choose your session clearance.

   4. Accept the default unless you have a reason not to.

      Press the Return key or click the OK button and be logged in.

2. Assume an administrative role that you have been assigned.

   1. Click the right mouse button in the middle of the Front Panel.

   2. Choose Assume administrative Role from the menu.

   3. At the password prompt, enter the password for that role.

To Remove Free Space (Optional)

1. As role admin, at label admin_low, unmount the audit partitions from the system by running the umount(1M) command in a profile shell.

   For example, on the audit file server egret:

   egret$ umount /etc/security/audit/egret egret$ umount /etc/security/audit/egret.1 egret$ umount /etc/security/audit/egret.2 egret$ umount /etc/security/audit/egret.3

2. Reduce reserved filesystem space on each partition to 0% with the command tunefs -m 0.

   The security administrator sets the reserved filesystem space (called the minfree limit) in the audit_control(4) file.

   For example, on the audit file server egret:

   egret$ tunefs -m 0 /etc/security/audit/egret egret$ tunefs -m 0 /etc/security/audit/egret.1 egret$ tunefs -m 0 /etc/security/audit/egret.2 egret$ tunefs -m 0 /etc/security/audit/egret.3

   Similarly, on the system willet:

   willet$ umount /etc/security/audit/willet willet$ tunefs -m 0 /etc/security/audit/willet

   See the tunefs(1M) man page for more information on the advantages and disadvantages of tuning a file system.

To Protect an Audit File System

1. As role secadmin, at label admin_low, set the appropriate file permissions on every audit file system while the file system is unmounted.

   For example, on the audit file server egret:

   egret$ chmod -R 750 /etc/security/audit/egret egret$ chmod -R 750 /etc/security/audit/egret.1 egret$ chmod -R 750 /etc/security/audit/egret.2 egret$ chmod -R 750 /etc/security/audit/egret.3

   On the system willet:

   willet$ chmod -R 750 /etc/security/audit/willet

2. As role secadmin, at label admin_high, set any Trusted Solaris security attribute defaults required by your site security policy on every audit file system while the file system is unmounted.

   To run the command at the label admin_high, you must create an admin_high workspace. Follow the procedure in To Create an Admin_High Workspace.

   For example, the following command on the audit file server egret should be repeated for all of its audit partitions:

   egret$ setfsattr -s “[admin_high]” /etc/security/audit/egret

   On the system willet:

   willet$ setfsattr -s “[admin_high]” /etc/security/audit/willet

   The -s option sets the partition's default sensitivity label for the audit files. See the setfsattr(1M) man page for more information.

   ---

   Note –

   The local audit file systems must already be in the host's /etc/vfstab file.

   ---

To Create an Audit Directory

1. As admin, at label admin_high, remount the local audit file systems.

   Follow the procedure in To Create an Admin_High Workspace to get an admin_high process.

   For example, on the audit file server egret:

   egret$ mount /etc/security/audit/egret egret$ mount /etc/security/audit/egret.1 egret$ mount /etc/security/audit/egret.2 egret$ mount /etc/security/audit/egret.3

   Similarly, on the system willet:

   willet$ mount /etc/security/audit/willet

2. Create a directory named files at the top of each mounted audit partition.

   For example, on the audit file server egret:

   egret$ mkdir /etc/security/audit/egret/files egret$ mkdir /etc/security/audit/egret.1/files egret$ mkdir /etc/security/audit/egret.2/files egret$ mkdir /etc/security/audit/egret.3/files

   On the system willet:

   willet$ mkdir /etc/security/audit/willet/files

To Share an Audit File System

1. In the role admin at label admin_low, open the Trusted Solaris Management Console, Scope=files toolbox.

2. Navigate to the Storage node, then the Mounts and Shares tool, and double-click the Shares tool.

3. Enter every local audit file system in the local host's dfstab(4) file.

   Follow the online help to share the /etc/security/audit/hostname directory.

   For example, the audit file server egret has the following entries:

   share -F nfs -o ro -d "local audit files" /etc/security/audit/egret
   share -F nfs -o rw=willet:audubon -d "audit files" /etc/security/audit/egret.1
   share -F nfs -o rw=grebe:audubon -d "audit files" /etc/security/audit/egret.2
   share -F nfs -o rw=sora:audubon -d "audit files" /etc/security/audit/egret.3

   The system willet has the following entry:

   share -F nfs -o ro -d "local audit files" /etc/security/audit/willet

To Mount an Audit File System

1. As role admin at label admin_low, on audubon, the audit administration server, create a mount point for every audit directory in the Trusted Solaris network.

   For example, on the audit administration server audubon:

   audubon$ mkdir /etc/security/audit/willet audubon$ mkdir /etc/security/audit/egret audubon$ mkdir /etc/security/audit/egret.1 …

2. As role admin, at label admin_low, enter every audit partition on the network in the audit administration server's vfstab(4) file.

   Mount audit directories with the read-write (rw) option. Mount remote partitions using the soft option.

   1. Click the Application Manager, double-click the System_Admin folder, and double-click the Set Mount Points action.

   2. Enter the mount points in the vfstab(4) file.

      The following shows part of the vfstab file on audubon:

      # egret is the main audit file server
      egret:/etc/security/audit/egret - /etc/security/audit/egret nfs - yes bg,soft,nopriv
      egret:/etc/security/audit/egret.1 - /etc/security/audit/egret.1 nfs - yes bg,soft,nopriv
      egret:/etc/security/audit/egret.2 - /etc/security/audit/egret.2 nfs - yes bg,soft,nopriv
      egret:/etc/security/audit/egret.3 - /etc/security/audit/egret.3 nfs - yes bg,soft,nopriv
      willet:/etc/security/audit/willet - /etc/security/audit/willet nfs - yes bg,soft,nopriv
      …

3. On each system, create the mount points for the remote audit file servers' partitions that are used by the system, and enter them in the vfstab(4) file. Do this as role admin, at label admin_low.

   For example, to create the mount points on the system willet:

   willet$ mkdir /etc/security/audit/egret willet$ mkdir /etc/security/audit/audubon.2

   1. Click the Application Manager, double-click the System_Admin folder, and double-click the Set Mount Points action.

   2. Enter the mount points in the vfstab(4) file.

      The following shows part of the vfstab file on willet:

      # egret is the main audit file server
      egret:/etc/security/audit/egret - /etc/security/audit/egret nfs - yes bg,soft,nopriv
      # audubon is the audit administration server
      audubon:/etc/security/audit/audubon.2 - /etc/security/audit/audubon.2 nfs - yes nopriv

To Reserve Free Space on an Audit File System

1. As role secadmin, at label admin_low, enter reserve free space in the audit_control(4) file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Control action.

2. Enter a value between 10 and 20 on the minfree: line.

   dir:/var/audit
   flags:
   minfree:20
   naflags:

3. Write the file and quit the editor.

To Specify the Audit File Storage Locations

1. As role secadmin, at label admin_low, enter audit storage locations in the audit_control file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Control action.

2. On the first system installed, enter its local audit file system as the value of the dir: line.

   The following shows the audit_control file for grebe, the NIS+ root master.

   dir:/etc/security/audit/grebe/files
   flags:
   minfree:20
   naflags:

3. When the audit file servers have been installed and configured, add their (mounted) filesystem names plus their top-level directory, files to the dir: entry.

   The mounted file systems are listed before the system's local file system, as in:

   dir:/etc/security/audit/egret/files
   dir:/etc/security/audit/egret.1/files
   dir:/etc/security/audit/grebe/files
   flags:
   minfree:20
   naflags:

4. Write the file and exit the editor.

5. As role secadmin in an admin_high profile shell, execute the audit -s command to have the audit daemon re-read the audit_control file and write audit records to the designated directory.:

   $ audit -s

   By default, the audit records have been stored in /var/audit. The audit records will now be stored in the first directory in the audit_control file.

To Set Audit Flags

1. As role secadmin, at label admin_low, enter system-wide audit flags in the audit_control(4) file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Control action.

2. Enter the na class in the naflags: line if your site is auditing non-attributable events.

   dir:/etc/security/audit/egret/files
   dir:/etc/security/audit/egret.1/files
   dir:/etc/security/audit/grebe/files
   flags:
   minfree:20
   naflags:na
   

3. Enter other classes in the flags: line if your system is auditing user-level events.

   dir:/etc/security/audit/egret/files
   dir:/etc/security/audit/egret.1/files
   dir:/etc/security/audit/grebe/files
   flags:lo,ad,-all,^-fc
   minfree:20
   naflags:na

   See Sample audit_control File for an explanation of the syntax of the audit flags' fields.

4. Write the file and exit the editor.

   ---

   Note –

   On a distributed system, the audit flags in the audit_control file must be identical on every host on the network. See To Distribute Audit Configuration Files for a process to distribute master copies of files to all hosts on the network.

   ---

To Set User Exceptions to the Audit Flags

The security administrator at label admin_low, enters user exceptions to system-wide audit flags in the user's Audit tab.

1. In the the role secadmin, launch the Solaris Management Console from the Application Manager and choose the toolbox appropriate for your site.

2. Under the User Accounts node, select a user.

3. In the user's Audit tab, enter the user exceptions, write the file, and exit the editor.

   Follow the online help for assistance. The following example shows the format of the audit_user file.

   For example, the following audit_user entry audits the role root for logins and logouts, and never audits the fc class, even if it is being audited for the system. The jane entry audits her for all flags specified in the audit_control file except for successful file_read events. Null events, no, are never audited.

   # User Level Audit User File
   #
   # File Format
   #
   #       username:always:never
   #
   root:lo:no,fc
   jane:all,^+fr:no
   

To Warn of Audit Trouble

1. As role admin, at label admin_low, create a mail alias to warn of audit trouble.

   1. If you are running a name service, on the master server of the name service, launch the Solaris Management Console from the Application Manager.

   2. Choose the toolbox that your site uses for administration, and select the Users node.

   3. Double-click the Mailing Lists node.

   4. From the Action menu, choose Add mailing list.

2. Create an alias called audit_warn for notifying its members of audit trouble.

   For example, this audit_warn alias emails the security administrator and the system administrator when the auditing subsystem needs attention.

   Mailing List Name: audit_warn
   Mailing List Recipients: secadmin@grebe,admin@grebe
   

To Set Audit Policy Permanently

1. As role secadmin, at label admin_low, enter permanent audit policy in the audit_startup(1M) file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Startup action.

2. Create a script that calls the auditconfig(1M) command with policy options.

   The sample audit_startup(1M) script below adds ACLs to audit records, halts the computer when its audit file systems are full, and at startup, prints the current audit policy to standard i/o.

   ---

   #!/bin/sh
   auditconfig -setpolicy +slabel,+acl
   auditconfig -setpolicy +ahlt
   auditconfig -getpolicy

   ---

3. Write the file and exit the editor

   ---

   Caution –

   To run auditing in an evaluated configuration, the cnt policy cannot be turned on; the ahlt policy (the default) cannot be turned off.

   ---

To Distribute Audit Configuration Files

In the Trusted Solaris 8 4/01 release, the audit_user file can be a NIS map or a NIS+ table, and does not need to be copied to each host. Sites that do not use a name service will want the same audit_user file on every system. If the site modifies the file on any system, it should be copied to all hosts.

1. During installation, as root, at label admin_low, create a directory on the first installed workstation to hold copies of the audit configuration files customized for your site.

   For example, on grebe, the first host in a network:

   # mkdir /export/home/tmp

2. Copy the modified files from the /etc/security directory to the /export/home/tmp directory.

   # cp /etc/security/audit_control /export/home/tmp/audit_control # cp /etc/security/audit_warn /export/home/tmp/audit_warn # cp /etc/security/audit_startup /export/home/tmp/audit_startup # cp /etc/security/audit_event /export/home/tmp/audit_event

   The directory would include your customized versions of audit_control, audit_startup, and audit_warn. If you have modified event-to-class mappings, it would include audit_event; if you have created new audit classes, it would include audit_class. It would not include audit_data.

3. Allocate the tape or diskette device.

   Follow the procedure in To Allocate and Deallocate Devices.

4. Run the tar(1) command to copy the contents of the /export/home/tmp directory to a tape or diskette.

   • To copy to tape:

     # cd /export/home/tmp # tar cv audit_control audit_warn audit_startup audit_event

   • To copy to diskette:

     # cd /export/home/tmp # tar cvf /dev/diskette \ audit_control audit_warn audit_startup audit_event

5. Deallocate the tape or diskette device and follow the instructions.

   Follow the procedure in To Deallocate a Device.

6. As root, at label admin_low, as each new host is configured, copy the files from the tape or diskette to the correct directory on the new system.

   1. Prepare the directory for the new files.

      # cd /etc/security # mv audit_control audit_control.orig # mv audit_startup audit_startup.orig # mv audit_warn audit_warn.orig # mv audit_event audit_event.orig

   2. Allocate the appropriate device at the label admin_low.

      Follow the procedure in To Allocate and Deallocate Devices.

   3. Copy the files.

      • To copy from tape:

        # tar xv audit_control audit_warn audit_startup audit_event

      • To copy from diskette:

        # tar xvf /dev/diskette \ audit_control audit_warn audit_startup audit_event

   4. Deallocate the device.

      Follow the procedure in To Deallocate a Device.

7. As role admin, at label admin_low, modify the audit_control file on each new system with that system's remote and local audit file systems.

To Allocate and Deallocate Devices

The Device Manager allocates and deallocates devices.

1. In an administrative role workspace at the label required, click the left mouse button on the triangle above the Style Manager icon on the Front Panel.

   The Tools subpanel is displayed.

2. Click the Device Manager icon once.

   

3. Double-click the device to be allocated.

   mag_tape_0 allocates a tape device. floppy_0 allocates a diskette.

4. Click OK in the label builder that appears.

   The file you load will be labeled admin_low.

To Deallocate a Device

1. Go to the workspace where the Device Manager was allocated.

2. Double-click the device to deallocate it.

   A window appears listing devices being deallocated.

3. When prompted, remove the tape or diskette from the drive and label it appropriately.

4. Click the top left button and select Close to close the Device Allocation Manager window.

Advanced Audit Setup (Tasks)

The following procedures describe how to modify the default audit classes and audit events, and to set a public object bit on files and folders to reduce unnecessary auditing.

To Add Audit Classes

1. As role secadmin, at label admin_low, add audit classes in the audit_classes file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Classes action.

2. Add the classes you planned in Planning a Site-Specific Event-to-Class Mapping, write the file, and exit the editor.

   ---

   Caution –

   Do not reassign the hexadecimal numbers already in use.

   ---

3. As role secadmin, at label admin_low, open the Audit Events action to add the new class to each event in the new class.

   For events in more than one class, use a comma (no space) to delimit the classes.

4. Write the file and exit the editor.

5. Make any changes to audit_control(4) and audit_user(4) to audit the events in the new classes.

   See To Set Audit Flags and To Set User Exceptions to the Audit Flags for details of the procedures.

   ---

   Note –

   On a distributed system, the audit_class, audit_event, audit_startup, and audit_user files must be identical on every host on the network. See To Distribute Audit Configuration Files for a process to distribute master copies of files to all hosts on the network.

   ---

6. Reboot, or as secadmin in an admin_low profile shell, run the auditconfig(1M) command with appropriate options.

   In the following example, the audit session ID is 159, and the new classes are gr (for graphic applications) and db (for databases applications).

   $ auditconfig -setsmask 159 gr,db

To Add Audit Events

1. As role secadmin, at label admin_low, add audit events in the audit_event(4) file.

   1. Open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Events action.

2. Add the events you planned in Planning a Site-Specific Event-to-Class Mapping, write the file, and exit the editor.

   For events in more than one class, use a comma (no space) to delimit the classes.

   ---

   Note –

   Third-party applications can use the event numbers 32768 through 65536 only. See for more information about event number assignment.

   ---

3. Make any changes to audit_control(4) and audit_user(4) to audit the events in the new classes.

   See To Set Audit Flags and To Set User Exceptions to the Audit Flags for details of the procedures.

   ---

   Note –

   On a distributed system, the audit_class, audit_event, audit_startup, and audit_user files must be identical on every host on the network. See To Distribute Audit Configuration Files for a process to distribute master copies of files to all hosts on the network.

   ---

4. Reboot, or as secadmin in an admin_low profile shell, run the auditconfig(1M) command with appropriate options.

   In the following example, the audit session ID is 159, and the new events are in the classes gr (for graphic applications) and db (for databases applications).

   $ auditconfig -setsmask 159 gr,db

To Change Event-Class Mappings

1. Change event-class mappings in the audit_control(4) file.

   1. As role secadmin, at label admin_low, open the System_Admin folder from the Application Manager.

   2. Double-click the Audit Events action.

2. Edit the file to change the class mapping for each event to be changed, write the file, and exit the editor.

   If you are changing events above number 2048, this is all you need to do.

   ---

   Note –

   On a distributed system, the audit_class, audit_event, audit_startup, and audit_user files must be identical on every host on the network. See To Distribute Audit Configuration Files for a process to distribute master copies of files to all hosts on the network.

   ---

3. If you modify a kernel event mapping (numbers 1 to 2047), restart auditing by doing one of the following:

   • Reboot the system, or

   • As role secadmin, at label admin_low, change the runtime event-to-class mappings:

     $ auditconfig -conf

To Set Public Object Bit

Setting the public object bit can reduce the size of the audit trail when the audit record includes successful accesses of files or directories. Successful viewing, listing, or listing of a file or directory's attributes will not be written to the audit record when the file's public object bit is set.

As role secadmin, at label admin_low, set the public object bit on a local directory of publicly accessible files using the setfattrflag(1) command with the -p 1 option.

The following command sets the public object bit on the /etc directory. A search of the /etc directory, or a read of files in the /etc directory will not result in an audit record.

$ setfattrflag -p 1 /etc $ getfattrflag /etc Multilevel directory: no Single level directory: no Public object: yes

Dynamic Auditing (Tasks)

Dynamic controls apply to one system at a time, since the audit command only applies to the current system where you are logged in. Use dynamic controls to test auditing on a system (estimate volume of records, for example), or to add an auditing flag without having to reboot the computer. However, if you make dynamic changes on one system for other than testing purposes, you should make the changes on all systems.

The following procedures work only when auditing is enabled.

To Determine Current Audit Policy

The auditconfig(1M) command enables an appropriately configured role to determine audit policy and to see what policies can be set. If your role is not configured to determine the policy, or if auditing is turned off, the command auditconfig -getpolicy returns an error. The following example was run by the role secadmin, at label admin_low:

$ auditconfig -getpolicy
	audit policies = none
$ auditconfig -lspolicy
policy string   description: 
	arge    include exec environment args in audit recs 
	argv    include exec args in audit recs 
	cnt     when no more space, drop recs and keep a count 
	group   include supplementary groups in audit recs 
	seq     include a sequence number in audit recs 
	trail   include trailer tokens in audit recs 
	path    allow multiple paths per event 
	acl     include ACL information in audit recs 
	ahlt    halt machine if we can't record an async event 
	slabel  include sensitivity labels in audit recs 
	passwd  include cleartext passwords in audit recs 
	windata_down include downgraded information in audit recs 
	windata_up   include upgraded information in audit recs 
	all     all policies 
	none    no policies 

To Create an Admin_High Workspace

To label files admin_high, to move files to an admin_high directory, to reset the audit daemon, and to make other changes in auditing requires an admin_high process. An admin_high process starts from an admin_high workspace.

1. Click the right button on the Front Panel and choose Assume secadmin Role from the menu.

   A secadmin role workspace becomes the current workspace.

2. In the current workspace, click the right button on the workspace name (secadmin) button and choose Change Workspace SL from the menu.

3. In the label builder, click the ADMIN_HIGH button, then click OK.

   The color of the workspace button turns to black, indicating an admin_high workspace. An admin_high workspace is available only to an administrative role.

To Set Audit Policy Temporarily

The auditconfig command enables you to change audit policy, such as whether to include acl information in the audit record. Since the audit policy variable is a dynamic kernel variable, the policy that you set is in effect until the computer next boots. See the auditconfig(1M) man page for a list of audit policy parameters.

The security administrator sets or changes audit policy. Policy changes are set at the label admin_low.

To set policies in one invocation of the command, or to override all current policies, separate the policies with commas (no spaces):

$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy argv,acl $ auditconfig -getpolicy audit policies = argv,acl

To add policies to the current policies, preface each added policy with a plus (+):

$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy +argv $ auditconfig -setpolicy +acl $ auditconfig --getpolicy audit policies = seq,trail,argv,acl

To remove policies from the current policies, preface each policy to be removed with a minus (-):

$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy -seq $ auditconfig -getpolicy audit policies = trail

In the examples above, the trail and seq tokens are added to debug audit trail discrepancies. To set policies permanently, enter the auditconfig command in the audit_startup(1M) script. See To Set Audit Policy Permanently for how to edit the script.

To run auditing in an evaluated configuration, the cnt policy cannot be turned on; the ahlt policy (the default) cannot be turned off.

To Change Audit Flags Dynamically

The auditconfig(1M) command enables you to change audit flags dynamically, such as adding extra flags to a user, a session, or a process while the user, session, or process is active. Since the flags are added dynamically, they are in effect until the user logs out, the session ends, or the process ends.

The security administrator sets or changes audit policy. Policy changes are set at the label admin_low.

To set a particular user to be additionally audited for successful file reads:

$ auditconfig -setumask audit_user_id +fr

To set a particular session to be additionally audited for failed file attribute access:

$ auditconfig -setsmask audit_session_id -fa

To set a particular process to be additionally audited for successful and unsuccessful file attribute modifications:

$ ps -ef | grep application-to-be-monitored $ auditconfig -setpmask process_id fm

To Stop the Audit Daemon

Only one audit daemon may run at a time. An attempt to start a second one will result in an error message, and the new one will exit. If there is a problem with the audit daemon, terminate the audit daemon gracefully, then restart it manually.

To stop the audit daemon in event of trouble, as role secadmin, at label admin_high:

$ audit -t

This is not recommended. Audit records may be lost.

To Start the Audit Daemon

The audit daemon starts when the computer is brought up to multiuser mode, and restarts when the audit daemon is instructed by the audit -s command to reread an audit configuration file.

To restart the audit daemon in event of trouble or a change to an audit configuration file, as role secadmin, at label admin_high:

$ audit -s

The pointer may be reset to the beginning of the list of audit directories when the administrator enters the audit -s command.

To Send Audit Records to a New Audit File

To change the current audit file for audit records being generated on the system, as role secadmin at label admin_high:

$ audit -n filename

The new file is created in the same directory as the current file. The directory must be able to contain files labeled admin_high.