System Administration Guide: Security Services

Part VII Solaris Auditing

This section provides information on the configuration, management, and use of the Solaris auditing subsystem.

Chapter 28 Solaris Auditing (Overview)

Solaris auditing keeps a record of how the system is being used. The audit service includes tools to assist with the analysis of the auditing data.

This chapter introduces how auditing works in the Solaris Operating System. The following is a list of the information in this chapter.

For planning suggestions, see Chapter 29, Planning for Solaris Auditing. For procedures to configure auditing at your site, see Chapter 30, Managing Solaris Auditing (Tasks). For reference information, see Chapter 31, Solaris Auditing (Reference).

What Is Auditing?

Auditing is the collecting of data about the use of system resources. The audit data provides a record of security-related system events. This data can then be used to assign responsibility for actions that take place on a host. Successful auditing starts with two security features: identification and authentication. At each login, after a user supplies a user name and password, a unique audit session ID is generated and associated with the user's process. The audit session ID is inherited by every process that is started during the login session. Even if a user changes identity within a single session, all user actions are tracked with the same audit session ID. For more details about changing identity, see the su(1M) man page.

The audit service makes the following possible:

During system configuration, you preselect which classes of audit records to monitor. You can also fine-tune the degree of auditing that is done for individual users.The following figure shows details of the flow of Solaris auditing.

Figure 28–1 The Flow of Auditing

Graphic shows identification and authentication for auditing,
then the flow from audit class preselection to plugin output.

After audit data is collected in the kernel, plugins distribute the data to the appropriate locations. Then, postselection tools enable you to reduce and examine interesting parts of the audit trail. For example, you can choose to review audit records for individual users or specific groups. You can examine all records for a certain type of event on a specific day. Or, you can select records that were generated at a certain time of day.

Systems that install non-global zones can audit all zones identically from the global zone. These systems can also be configured to collect different records in the non-global zones. For more information, see Auditing and Solaris Zones.

How Does Auditing Work?

Auditing generates audit records when specified events occur. Most commonly, events that generate audit records include the following:

Audit records are generated from three sources:

Once the relevant event information has been captured, the information is formatted into an audit record. The record is then written to audit files. Complete audit records are stored in binary format. With the Solaris 10 release, audit records can also be logged by the syslog utility.

Audit files in binary format can be stored in a local file system. The files can also be stored on NFS-mounted file servers. The location can include multiple partitions on the same system, partitions on different systems, or partitions on systems on different but linked networks. The collection of audit files that are linked together is considered an audit trail. Audit records accumulate in audit files chronologically. Contained in each audit record is information that identifies the event, what caused the event, the time of the event, and other relevant information.

Audit records can also be monitored by using the syslog utility. These audit logs can be stored locally. Or, the logs can be sent to a remote system over the UDP protocol. For more information, see Audit Logs.

How Is Auditing Related to Security?

Solaris auditing helps to detect potential security breaches by revealing suspicious or abnormal patterns of system usage. Solaris auditing also provides a means to trace suspect actions back to a particular user, thus serving as a deterrent. Users who know that their activities are being audited are less likely to attempt malicious activities.

To protect a computer system, especially a system on a network, requires mechanisms that control activities before system processes or user processes begin. Security requires tools that monitor activities as the activities occur. Security also requires reports of activities after the activities have happened. Initial configuration of Solaris auditing requires that parameters be set before users log in or system processes begin. Most auditing activities involve monitoring current events and reporting those events that meet the specified parameters. How Solaris auditing monitors and reports these events is discussed in detail in Chapter 29, Planning for Solaris Auditing and Chapter 30, Managing Solaris Auditing (Tasks).

Auditing cannot prevent hackers from unauthorized entry. However, the audit service can report, for example, that a specific user performed specific actions at a specific time and date. The audit report can identify the user by entry path and user name. Such information can be reported immediately to your terminal and to a file for later analysis. Thus, the audit service provides data that helps you determine the following:

Audit Terminology and Concepts

The following terms are used to describe the audit service. Some definitions include pointers to more complete descriptions.

Table 28–1 Solaris Auditing Terms

Term 

Definition 

Audit class 

A grouping of audit events. Audit classes provide a way to select a group of events to be audited. For more information, see Audit Classes and Preselection.

Audit directory 

A repository of audit files in binary format. For a description of the types of audit directories, see Audit Logs.

Audit event 

A security-related system action that is audited. For ease of selection, events are grouped into audit classes. For a discussion of the system actions that can be audited, see Audit Events.

Audit policy 

A set of auditing options that you can enable or disable at your site. These options include whether to record certain kinds of audit data. The options also include whether to suspend auditable actions when the audit trail is full. For more information, see Determining Audit Policy.

Audit record 

Audit data that is stored in audit files. An audit record describes a single audit event. Each audit record is composed of audit tokens. For more information about audit records, see Audit Records and Audit Tokens.

Audit token 

A field of an audit record or event. Each audit token describes an attribute of an audit event, such as a user, a program, or other object. For descriptions of all the audit tokens, see Audit Token Formats.

Audit trail 

A collection of one or more audit files that store the audit data from all systems that run the audit service. For more information, see Audit Trail.

Preselection 

Preselection is the choice of which audit classes to monitor before you enable the audit service. The audit events of preselected audit classes appear in the audit trail. Audit classes that are not preselected are not audited, so their events do not appear in the audit trail. A postselection tool, the auditreduce command, selects records from the audit trail. For more information, see Audit Classes and Preselection.

Public objects 

A public object is a file that is owned by the root user and readable by the world. For example, files in the /etc directory and the /usr/bin directory are public objects. Public objects are not audited for read-only events. For example, even if the file_read (fr) audit class is preselected, the reading of public objects is not audited. You can override the default by changing the public audit policy option.

Audit plugins 

Modules that transfer the audit records in the kernel queue to a specified location. The audit_binfile.so plugin creates binary audit files (the audit trail). The audit_syslog.so plugin filters selected audit records to the syslog logs. For more information, see Audit Plugin Modules.

Audit Events

Security-relevant system actions can be audited. These auditable actions are defined as audit events. Audit events are listed in the /etc/security/audit_event file. Each audit event is defined in the file by an event number, a symbolic name, a short description, and the set of audit classes to which the event belongs. For more information on the audit_event file, see the audit_event(4) man page.

For example, the following entry defines the audit event for the exec() system call:


7:AUE_EXEC:exec(2):ps,ex

When you preselect for auditing either the audit class ps or the audit class ex, then exec() system calls are recorded in the audit trail.

Solaris auditing handles attributable and nonattributable events. Audit policy divides events into synchronous and asynchronous events. as follows:

When the class to which an audit event belongs is preselected for auditing, the event is recorded in the audit trail. For example, when you preselect the ps and na audit classes for auditing, the exec() system calls and system boot actions, among other events, are recorded in the audit trail.

In addition to the audit events that are defined by the Solaris audit service, third-party applications can generate audit events. Audit event numbers from 32768 to 65535 are available for third-party applications.

Audit Classes and Preselection

Each audit event belongs to an audit class or classes. Audit classes are convenient containers for large numbers of audit events. When you preselect a class to be audited, you specify that all the events in that class should be recorded in the audit trail. You can preselect for events on a system and for events initiated by a particular user. After the audit service is running, you can dynamically add or remove audit classes from the preselected classes.

A postselection command, auditreduce, enables you to select records from the preselected audit records. For more information, see Examining the Audit Trail and the auditreduce(1M) man page.

Audit classes are defined in the /etc/security/audit_class file. Each entry contains the audit mask for the class, the name for the class, and a descriptive name for the class. For example, the ps and na class definitions appear in the audit_class file as follows:


0x00100000:ps:process start/stop
0x00000400:na:non-attribute

There are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in the audit_class(4) man page.

The mapping of audit events to classes is configurable. You can remove events from a class, add events to a class, and create a new class to contain selected events. For the procedure, see How to Change an Audit Event's Class Membership.

Audit Records and Audit Tokens

Each audit record records the occurrence of a single audited event. The record includes information such as who did the action, which files were affected, what action was attempted, and where and when the action occurred. The following example shows a login audit record:


header,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login
return,success,0

The type of information that is saved for each audit event is defined by a set of audit tokens. Each time an audit record is created for an event, the record contains some or all of the tokens that are defined for the event. The nature of the event determines which tokens are recorded. In the preceding example, each line begins with the name of the audit token. The content of the audit token follows the name. Together, the four audit tokens comprise the login audit record.

For a detailed description of the structure of each audit token with an example of praudit output, see Audit Token Formats. For a description of the binary stream of audit tokens, see the audit.log(4) man page.

Audit Plugin Modules

You can specify audit plugin modules to handle the records that your preselection has placed in the audit queue. The plugins are entries in the audit_control file.

For the syntax of the audit_control file, see the audit_control(4) man page. For examples, see the tasks in Configuring Audit Files (Task Map).

For information about the plugins, see the audit_binfile(5), audit_syslog(5), audit_remote(5), and audit_control(4) man pages.

Audit Logs

Audit records are collected in audit logs. Solaris auditing provides two output modes for audit logs. Logs that are called audit files store audit records in binary format. The set of audit files from a system or site provide a complete audit record. The complete audit record is called the audit trail.

The syslog utility collects and stores text version summaries of the audit record. A syslog record is not complete. The following example shows a syslog entry for a login audit record:


Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

A site can store audit records in both formats. You can configure the systems at your site to use binary mode, to use syslog mode, or to use both modes. The following table compares binary audit records with syslog audit records.

Table 28–2 Comparison of Binary Audit Records With syslog Audit Records

Feature 

Binary Records 

syslog Records

Protocol 

Writes to the file system 

Uses UDP for remote logging 

Data type 

Binary 

Text 

Record length 

No limit 

Up to 1024 characters per audit record 

Location 

Stored on local disk, and in directories that are mounted by using NFS 

Stored in a location that is specified in the syslog.conf file

How to configure 

Edit audit_control file, and protect and NFS-mount audit directories

Edit audit_control file, and edit syslog.conf file

How to read 

Typically, in batch mode 

Browser output in XML 

In real time, or searched by scripts that you have created for syslog

Plain text output 

Completeness 

Guaranteed to be complete, and to appear in the correct order 

Are not guaranteed to be complete 

Timestamp 

Greenwich Mean Time (GMT) 

Time on the system that is being audited 

Binary records provide the greatest security and coverage. Binary output meets the requirements of security certifications, such as the Common Criteria Controlled Access Protection Profile (CAPP). The records are written to a file system that you protect from snooping. On a single system, all binary records are collected and are displayed in order. The GMT timestamp on binary logs enables accurate comparison when systems on one audit trail are distributed across time zones. The praudit -x command enables you to view the records in a browser in XML. You can also use scripts to parse the XML output.

In contrast, the syslog records provide greater convenience and flexibility. For example, you can collect the syslog data from a variety of sources. Also, when you monitor audit.notice events in the syslog.conf file, the syslog utility logs an audit record summary with the current timestamp. You can use the same management and analysis tools that you have developed for syslog messages from a variety of sources, including workstations, servers, firewalls, and routers. The records can be viewed in real time, and can be stored on a remote system.

By using syslog.conf to store audit records remotely, you protect log data from alteration or deletion by an attacker. On the other hand, when audit records are stored remotely, the records are susceptible to network attacks such as denial of service and spoofed source addresses. Also, UDP can drop packets or can deliver packets out of order. The limit on syslog entries is 1024 characters, so some audit records could be truncated in the log. On a single system, not all audit records are collected. The records might not display in order. Because each audit record is stamped with the local system's date and time, you can not rely on the timestamp to construct an audit trail for several systems.

For more information on audit logs, refer to the following:

Storing the Audit Trail

An audit directory holds audit files in binary format. A typical installation uses many audit directories. The contents of all audit directories comprise the audit trail. Audit records are stored in audit directories in the following order:

The directories are specified in the audit_control file. A directory is not used until a directory that is earlier in the list is full. For an annotated audit_control file with a list of directory entries, see Example 30–3.

Placing the audit files in the default audit root directory assists the audit reviewer when reviewing the audit trail. The auditreduce command uses the audit root directory to find all files in the audit trail. The default audit root directory is /etc/security/audit. This directory is symbolically linked to /var/audit. Audit files in directories that are named /var/audit/hostname/files are easily found by the auditreduce command. For more information, see auditreduce Command.

Examining the Audit Trail

The audit service provides commands to combine and reduce files from the audit trail. The auditreduce command can merge audit files from the audit trail. The command can also filter files to locate particular events. The praudit command reads the binary files. Options to the praudit command provide output that is suitable for scripting and for browser display.

Auditing on a System With Zones

A zone is a virtualized operating system environment that is created within a single instance of the Solaris OS. The audit service audits the entire system, including activities in zones. A system that has installed non-global zones can run a single audit service to audit all zones identically. Or, it can configure one audit service per zone, including the global zone.

Sites that satisfy the following conditions can run a single audit service:

Sites that satisfy the following conditions can run one audit service per zone:

The advantages of per-zone auditing are a customized audit trail for each zone, and the ability to disable auditing on a zone by zone basis. These advantages can be offset by the administrative overhead. The zone administrator customizes every audit configuration file. Each zone runs its own audit daemon, and has its own audit queue and audit logs. The zone's audit log files must be managed.

Chapter 29 Planning for Solaris Auditing

This chapter describes how to set up the audit service for your Solaris installation. In particular, the chapter covers issues that you need to consider before you enable the audit service. The following is a list of the planning information in this chapter:

For an overview of auditing, see Chapter 28, Solaris Auditing (Overview). For procedures to configure auditing at your site, see Chapter 30, Managing Solaris Auditing (Tasks). For reference information, see Chapter 31, Solaris Auditing (Reference).

Planning Solaris Auditing (Task Map)

The following task map points to the major tasks that are required for planning disk space and what events to record.

Task 

For Instructions 

Determine auditing strategy for non-global zones 

How to Plan Auditing in Zones

Plan storage space for the audit trail 

How to Plan Storage for Audit Records

Determine who and what to audit 

How to Plan Who and What to Audit

Planning Solaris Auditing (Tasks)

You want to be selective about what kinds of activities are audited. At the same time, you want to collect useful audit information. Audit files can quickly grow to fill the available space, so you should allocate enough disk space. You also need to carefully plan who to audit and what to audit.

ProcedureHow to Plan Auditing in Zones

If your system has implemented zones, you have two audit configuration possibilities:

For a discussion of the trade-offs, see Auditing on a System With Zones.

  1. Choose one of the following methods.

    • OPTION 1 - Configure a single audit service for all zones.

      Auditing all zones identically can create a single-image audit trail. A single-image audit trail occurs when all zones on a system are part of one administrative domain. The audit records can then be easily compared, because the records in every zone are preselected with identical settings.

      This configuration treats all zones as part of one system. The global zone runs the only audit daemon on a system, and collects audit logs for every zone. You customize audit configuration files only in the global zone, then copy the audit configuration files to every non-global zone.

      1. Copy the audit_control file from the global zone to every non-global zone.

      2. Use the same audit_user database for every zone.

        The audit_user database might be a local file, or you might get it from a shared naming service.

      3. Enable the audit records to be selected by zone.

        To put the zone name as part of the audit record, set the zonename policy in the global zone. The auditreduce command can then select audit events by zone from the audit trail. For an example, see the auditreduce(1M) man page.

      To plan a single-image audit trail, refer to How to Plan Who and What to Audit. Start with the first step. The global zone administrator must also set aside storage, as described in How to Plan Storage for Audit Records.

    • OPTION 2 - Configure one audit service per zone.

      Choose to configure per-zone auditing if different zones have different naming service files, or if zone administrators want to control auditing in their zones.

      • When you configure per-zone auditing, you must configure the global zone for auditing. You set the perzone audit policy in the global zone. To set audit policy, see How to Configure Per-Zone Auditing.


        Note –

        If naming service files are customized in non-global zones, and perzone policy is not set, then careful use of the audit tools is required to select usable records. A user ID in one zone can refer to a different user from the same ID in a different zone.


      • To generate records that can be traced to their originating zone, set the zonename audit policy in the global zone. In the global zone, run the auditreduce command with the zonename option. Then, in the zonename zone, run the praudit command on the auditreduce output.

      • Each zone administrator configures the audit files for the zone.

        A non-global zone administrator can set all policy options except perzone and ahlt.

      • Each zone administrator can enable or disable auditing in the zone.

      If you customize audit configuration files in every zone, use How to Plan Who and What to Audit to plan for every zone. You can skip the first step. Each zone administrator must also set aside storage for every zone, as described in How to Plan Storage for Audit Records.

ProcedureHow to Plan Storage for Audit Records

The audit trail requires dedicated file space. The dedicated file space for audit files must be available and secure. Each system should have several audit directories that are configured for audit files. You should decide how to configure the audit directories as one of the first tasks before you enable auditing on any systems. The following procedure covers the issues to be resolved when you plan for audit trail storage.

Before You Begin

If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.

  1. Determine how much auditing your site needs.

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

    For guidance on how to reduce space requirements while still maintaining site security, as well as how to design audit storage, see Controlling Auditing Costs and Auditing Efficiently.

  2. Determine which systems are to be audited.

    On those systems, allocate space for at least one local audit directory. To specify the audit directories, see Example 30–3.

  3. Determine which systems are to store audit files.

    Decide which servers are to hold the primary and secondary audit directories. For examples of configuring disks for audit directories, see How to Create Partitions for Audit Files.

  4. Name the audit directories.

    Create a list of all the audit directories that you plan to use. For naming guidelines, see Storing the Audit Trail and auditreduce Command.

  5. Determine which systems are to use which audit directories.

    Create a map that shows which system should use which audit directory. The map helps you to balance the auditing activity. For an illustration, see Figure 31–1 and Figure 31–2.

ProcedureHow to Plan Who and What to Audit

Before You Begin

If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.

  1. Determine if you want a single-system image audit trail.

    Systems within a single administrative domain can create a single-system image audit trail. If your systems use different naming services, start with the next step. You should complete the rest of the planning steps for every system.

    A single-system image audit trail treats the systems that are being audited as one machine. To create a single-system image audit trail for a site, every system in the installation should be configured as follows:

    • Use the same naming service.

      To interpret the audit records, two commands are used, auditreduce and praudit. For correct interpretation of the audit records, the passwd, hosts, and audit_user files must be consistent.

    • Use the same audit service settings for all systems. For information about displaying and modifying the service settings, see the auditconfig(1M) man page.

    • Use the same audit_warn, audit_event, and audit_class files for all systems.

    • Use the same audit_user database. The database can be in a naming service such as NIS or LDAP.

    • Have identical flags, naflags, and plugin entries in the audit_control file.

  2. Determine the audit policy.

    Use the auditconfig -lspolicy command to see a short description of available policy options. By default, only the cnt policy is turned on. For a fuller discussion, see Step 8.

    For the effects of the policy options, see Determining Audit Policy. To set audit policy, see How to Configure Audit Policy.

  3. Determine if you want to modify event-to-class mappings.

    In many situations, the default mapping is sufficient. However, if you add new classes, change class definitions, or determine that a record of a specific system call is not useful, you might also need to move an event to a different class.

    For an example, see How to Change an Audit Event's Class Membership.

  4. Determine which audit classes to preselect.

    The best time to add audit classes or to change the default classes is before you start the audit service.

    The audit class values of the flags, naflags, and plugin entries in the audit_control file apply to all users and processes. The preselected classes determine whether an audit class is audited for success, for failure, or for both.

    To preselect audit classes, see How to Modify the audit_control File.

  5. Determine user exceptions to the system-wide preselected audit classes.

    If you decide that some users should be audited differently from the system-wide preselected audit classes, modify the individual users' entries in the audit_user database.

    For an example, see How to Change a User's Audit Characteristics.

  6. Determine the minimum free disk space.

    When disk space on an audit file system drops below the minfree percentage, the auditd daemon switches to the next available audit directory. The daemon then sends a warning that the soft limit has been exceeded.

    To set the minimum free disk space, see Example 30–4.

  7. Decide how to manage the audit_warn email alias.

    The audit_warn script is run whenever the audit system needs to notify you of a situation that requires administrative attention. By default, the audit_warn script sends email to an audit_warn alias and sends a message to the console.

    To set up the alias, see How to Configure the audit_warn Email Alias.

  8. Decide what action to take when all the audit directories are full.

    By default, when the audit trail overflows, the system continues to work. The system counts the audit records that are dropped, but does not record the events. For greater security, you can disable the cnt policy, and enable the ahlt policy. The ahlt policy stops the system when an asynchronous event cannot be placed in the audit queue.

    For a discussion of these policy options, see Audit Policies for Asynchronous and Synchronous Events. To configure these policy options, see Example 30–13.

  9. Decide whether to collect audit records in binary format, in syslog format, or in both formats.

    For overview information, see Audit Logs.

    For an example, see How to Configure syslog Audit Logs.

Determining Audit Policy

Audit policy determines the characteristics of the audit records for the local system. You use the auditconfig command to set these policies. For more information, see the auditconfig(1M) man page.

Most audit policy options are disabled by default to minimize storage requirements and system processing demands. These options are stored as properties of the audit service and determine the policy options that are in effect at system boot or when the service is restarted. For more information about the audit service, see Solaris Audit Service.

Use the following table to determine if the needs of your site justify the additional overhead that results from enabling one or more audit policy options.

Table 29–1 Effects of Audit Policy Options

Policy Name 

Description 

Why Change the Policy Option? 

ahlt

This policy applies to asynchronous events only. When disabled, this policy allows the event to complete without an audit record being generated. 

When enabled, this policy stops the system when the audit file systems are full. Administrative intervention is required to clean up the audit queue, make space available for audit records, and reboot. This policy can only be enabled in the global zone. The policy affects all zones. 

The disabled option makes sense when system availability is more important than security. 

The enabled option makes sense in an environment where security is paramount. 

arge

When disabled, this policy omits environment variables of an executed program from the exec audit record.

When enabled, this policy adds the environment variables of an executed program to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.

The disabled option collects much less information than the enabled option. 

The enabled option makes sense when you are auditing a few users. The option is also useful when you have suspicions about the environment variables that are being used in exec programs.

argv

When disabled, this policy omits the arguments of an executed program from the exec audit record.

When enabled, this policy adds the arguments of an executed program to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.

The disabled option collects much less information than the enabled option. 

The enabled option makes sense when you are auditing a few users. The option is also useful when you have reason to believe that unusual exec programs are being run.

cnt

When disabled, this policy blocks a user or application from running. The blocking happens when audit records cannot be added to the audit trail because no disk space is available. 

When enabled, this policy allows the event to complete without an audit record being generated. The policy maintains a count of audit records that are dropped. 

The disabled option makes sense in an environment where security is paramount. 

The enabled option makes sense when system availability is more important than security. 

group

When disabled, this policy does not add a groups list to audit records. 

When enabled, this policy adds a groups list to every audit record as a special token.

The disabled option usually satisfies requirements for site security. 

The enabled option makes sense when you need to audit which groups are generating audit events. 

path

When disabled, this policy records in an audit record at most one path that is used during a system call. 

When enabled, this policy records every path that is used in conjunction with an audit event to every audit record. 

The disabled option places at most one path in an audit record. 

The enabled option enters each file name or path that is used during a system call in the audit record as a path token.

perzone

When disabled, this policy maintains a single audit configuration for a system. One audit daemon runs in the global zone. Audit events in non-global zones can be located in the audit record by preselecting the zonename audit token.

When enabled, this policy maintains separate audit configuration, audit queue, and audit logs for each zone. A separate version of the audit daemon runs in each zone. This policy can be enabled in the global zone only. 

The disabled option is useful when you have no special reason to maintain a separate audit log, queue, and daemon for each zone. 

The enabled option is useful when you cannot monitor your system effectively by simply preselecting the zonename audit token.

public

When disabled, this policy does not add read-only events of public objects to the audit trail when the reading of files is preselected. Audit classes that contain read-only events include fr, fa, and cl.

When enabled, this policy records every read-only audit event of public objects if an appropriate audit class is preselected.

The disabled option usually satisfies requirements for site security. 

The enabled option is rarely useful. 

seq

When disabled, this policy does not add a sequence number to every audit record. 

When enabled, this policy adds a sequence number to every audit record. The sequence token holds the sequence number.

The disabled option is sufficient when auditing is running smoothly. 

The enabled option makes sense when the cnt policy is enabled. The seq policy enables you to to determine when data was discarded.

trail

When disabled, this policy does not add a trailer token to audit records.

When enabled, this policy adds a trailer token to every audit record.

The disabled option creates a smaller audit record. 

The enabled option clearly marks the end of each audit record with a trailer token. The trailer token is often used in conjunction with the sequence token. The trailer token provides easier and more accurate resynchronization of audit records.

zonename

When disabled, this policy does not include a zonename token in audit records.

When enabled, this policy includes a zonename token in every audit record from a non-global zone.

The disabled option is useful when you do not need to compare audit behavior across zones. 

The enabled option is useful when you want to isolate and compare audit behavior across zones. 

Audit Policies for Asynchronous and Synchronous Events

Together, the ahlt policy and the cnt policy govern what happens when the audit queue is full and cannot accept more events. The policies are independent and related. The combinations of the policies have the following effects:

Controlling Auditing Costs

Because auditing consumes system resources, you must control the degree of detail that is recorded. When you decide what to audit, consider the following costs of auditing:

Cost of Increased Processing Time of Audit Data

The cost of increased processing time is the least significant of the costs of auditing. The first reason is that auditing generally does not occur during computation-intensive tasks, such as image processing, complex calculations, and so forth. The other reason is that the cost for single-user systems is usually small enough to ignore.

Cost of Analysis of Audit Data

The cost of analysis is roughly proportional to the amount of audit data that is collected. The cost of analysis includes the time that is required to merge and review audit records. Cost also includes the time that is required to archive the records and keep the records in a safe place.

The fewer records that you generate, the less time that is required to analyze the audit trail. Upcoming sections, Cost of Storage of Audit Data and Auditing Efficiently, describe ways to audit efficiently. Efficient auditing reduces the amount of audit data, while still providing enough coverage to achieve your site's security goals.

Cost of Storage of Audit Data

Storage cost is the most significant cost of auditing. The amount of audit data depends on the following:

Because these factors vary from site to site, no formula can predetermine the amount of disk space to set aside for audit data storage. Use the following information as a guide:

Auditing Efficiently

The following techniques can help you achieve your organization's security goals while auditing more efficiently.

Chapter 30 Managing Solaris Auditing (Tasks)

This chapter presents procedures to help you set up and manage a Solaris system that is audited. This chapter also includes instructions for administering the audit trail. The following is a list of the information in this chapter.

For an overview of the audit service, see Chapter 28, Solaris Auditing (Overview). For planning suggestions, see Chapter 29, Planning for Solaris Auditing. For reference information, see Chapter 31, Solaris Auditing (Reference).

Solaris Auditing (Task Map)

The following task map points to the major tasks that are required to manage auditing. The tasks are ordered.

Task 

Description 

For Instructions 

1. Plan for auditing 

Contains configuration issues to decide before you configure the audit service. 

Planning Solaris Auditing (Task Map)

2. Configure audit files 

Defines which events, classes, and users require auditing. 

Configuring Audit Files (Task Map)

3. Configure and enable auditing 

Configures each host for disk space and other audit service requirements. Then, starts the audit service. 

Configuring and Enabling the Audit Service (Task Map)

On a host that has installed non-global zones, configure one audit service for the system, or one audit service per zone. 

Configuring the Audit Service in Zones (Tasks)

4. Manage audit records 

Collects and analyzes the audit data. 

Managing Audit Records (Task Map)

Configuring Audit Files (Task Map)

The following task map points to the procedures for configuring files to customize auditing at your site. Most of the tasks are optional.

Task 

Description 

For Instructions 

Select audit classes, and customize audit_control settings

Involves: 

  • Preselecting system-wide audit classes

  • Specifying the audit directories for each system

  • Setting disk space limits on audit file systems

How to Modify the audit_control File

(Optional) Log audit events in two modes 

Enables you to monitor audit events in real time, in addition to storing audit records in binary format. 

How to Configure syslog Audit Logs

(Optional) Change audit characteristics for users 

Sets user-specific exceptions to the system-wide preselected audit classes. 

How to Change a User's Audit Characteristics

(Optional) Add audit classes 

Reduces the number of audit records by creating a new audit class to hold events. 

How to Add an Audit Class

(Optional) Change event-to-class mappings 

Reduces the number of audit records by changing the event-class mapping. 

How to Change an Audit Event's Class Membership

Configuring Audit Files (Tasks)

Before you enable auditing on your network, you can customize the audit configuration files for your site auditing requirements. You can also restart the audit service or reboot the local system to read changed configuration files after the audit service has been enabled. However, the recommended practice is to customize your audit configuration as much as possible before you start the audit service.

If you have implemented zones, you can choose to audit all zones from the global zone. To differentiate between zones in the audit output, you can set the zonename policy option. Alternatively, to audit non-global zones individually, you can set the perzone policy in the global zone and customize the audit configuration files in the non-global zones. For an overview, see Auditing and Solaris Zones. For planning, see How to Plan Auditing in Zones. For procedures, see Configuring the Audit Service in Zones (Tasks).

ProcedureHow to Modify the audit_control File

The /etc/security/audit_control file configures system-wide auditing. The file determines which events are audited, when audit warnings are issued, and the location of the audit files.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

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


    # cp /etc/security/audit_control /etc/security/audit_control.orig
    
  3. Modify the audit_control file for your site.

    Each entry has the following format:


    keyword:value
    
    keyword

    Defines the type of line. The types are flags, naflags, and plugin.

    For explanations of the keywords, see the following examples.

    value

    Specifies data that is associated with the line type.


    Note –

    To specify the locations of audit directories, use the p_dir attribute to the audit_binfile.so plugin. To specify the minimum free space, use the p_minfree attribute.


  4. (Optional) Verify the syntax of the file.


    # audit -v /etc/security/audit_control
    syntax ok

Example 30–1 Preselecting Audit Classes for All Users

The flags line in the audit_control file defines which classes of attributable events are audited for all users on the system. The classes are separated by commas. White space is allowed. In this example, the events in the lo and ap classes are audited for all users.


## audit_control file
flags:lo,ap
naflags:lo
plugin:name=...

To see which events are assigned to a class, read the audit_event file. You can also use the auditrecordcommand, as shown in Example 30–24.



Example 30–2 Preselecting Nonattributable Events

In this example, all events in the na class, and all login events that are not attributable, are audited.


## audit_control file
flags:lo
naflags:lo,na
plugin:name=...


Example 30–3 Specifying the Location of Binary Audit Data

The p_dir flag to the audit_binfile.so plugin lists which audit file systems to use for binary audit data. In this example, three locations for binary audit data are defined. The directories are listed in order from the primary directory to the directory of last resort. The plugin line does not contain a line break.


## audit_control file
##
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/egret.1/files,
/var/audit/egret.2/files,/var/audit

To set up file systems to hold audit binary audit data, see How to Create Partitions for Audit Files.



Example 30–4 Changing the Soft Limit for Warnings

In this example, the minimum free-space level for all audit file systems is set so that a warning is issued when only 10 percent of the file system is available.

The plugin line does not contain a line break.


## audit_control file
#
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/examplehost.1/files,
/var/audit/examplehost.2/files,/var/audit/localhost/files; p_minfree=10

The audit_warn alias receives the warning. To set up the alias, see How to Configure the audit_warn Email Alias.


ProcedureHow to Configure syslog Audit Logs

You can instruct the audit service to copy some or all of the collected audit records in the audit queue to syslog. In the following procedure, you save binary audit data and text audit data. The collected text audit data is a subset of the binary data.

Before You Begin

You must preselect audit classes. Preselected audit classes are specified in the flags line and the naflags line of the audit_control file. You can also preselect classes for individual users in the audit_user file and dynamically add audit classes with the auditconfig command.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

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


    # cp /etc/security/audit_control /etc/security/audit_control.save
    
  3. Add an audit_syslog.so plugin entry.


    ## audit_control file
    flags:lo,ss
    naflags:lo,na
    plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20;
    plugin:name=audit_syslog.so;p_flags=+lo,-ss
    

    A plugin entry has the following format:


    plugin:name=name; qsize=max-queued-records;p_*=value
    
    • name=name – Lists the name of the plugin. The valid values are audit_binfile.so and audit_syslog.so.

    • qsize=max-queued-records – Specifies the maximum number of records to queue for audit data that is being sent to the plugin. This attribute is optional.

    • p_*=value – Specifies plugin-specific attributes. The audit_syslog.so plugin accepts p_flags. The audit_binfile.so plugin accepts p_dir, p_minfree and p_fsize.

      The audit_remote.so plugin accepts p_hosts, p_retries and p_timeout

    For more information about the plugin-specific attributes, see the OBJECT ATTRIBUTES section of the audit_binfile(5) and audit_syslog(5) man pages. For the audit_remote.so plugin, see the audit_remote(5) man page.

  4. Add an audit.notice entry to the syslog.conf file.

    The entry includes the location of the log file.


    # cat /etc/syslog.conf
    …
    audit.notice       /var/adm/auditlog

    Do not store text logs where the binary audit files are stored. The auditreduce command, which reads binary audit files, assumes that all files in an audit partition are binary audit files.

  5. Create the log file.


    # touch /var/adm/auditlog
    
  6. Refresh the configuration information for the syslog service.


    # svcadm refresh system/system-log
    
  7. Regularly archive the syslog log files.

    The audit service can generate extensive output. To manage the logs, see the logadm(1M) man page.


Example 30–5 Specifying Audit Classes for syslog Output

In the following example, the syslog utility collects a subset of the preselected audit classes.


## audit_user file
jdoe:pf

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/host.1/files,
/var/audit/host.2/files,/var/audit/localhost/files; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-na,-ss,+pf

The flags and naflags entries instruct the system to collect all login/logout, nonattributable, and change of system state audit records in binary format. The audit_syslog.so plugin entry instructs the syslog utility to collect only failed logins, failed nonattributable events, and failed changes of system state. For the jdoe user, the binary audit record includes all uses of a profile-aware shell. The syslog utility collects successful profile-aware commands. The pf class is created in Example 30–10.



Example 30–6 Putting syslog Audit Records on a Remote System

You can change the audit.notice entry in the syslog.conf file to point to a remote system. In this example, the name of the local system is example1. The remote system is remote1.


example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

The audit.notice entry in the syslog.conf file on the remote1 system points to the log file.


remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog


Example 30–7 Using Plugins in the audit_control File

The preferred method for specifying non-flags information in the audit_control file is to use the plugin entry. In this example, the audit flags are selected, then the plugin information is listed.


## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_minfree=10; p_dir=/var/audit
plugin:name=audit_syslog.so; p_flags=+lo

ProcedureHow to Change a User's Audit Characteristics

Definitions for each user are stored in the audit_user database. These definitions modify, for the specified user, the preselected classes in the audit_control file. The nsswitch.conf file determines if a local file or if a naming service database is used. To calculate the user's final audit preselection mask, see Process Audit Characteristics.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

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


    # cp /etc/security/audit_user /etc/security/audit_user.orig
    
  3. Add new entries to the audit_user database.

    In the local database, each entry has the following format:


    username:always-audit:never-audit
    
    username

    Selects the name of the user to be audited.

    always-audit

    Selects the list of audit classes that should always be audited for the specified user.

    never-audit

    Selects the list of audit classes that should never be audited for the specified user.

    You can specify multiple classes by separating the audit classes with commas.

    The audit_user entries are in effect at the user's next login.


Example 30–8 Changing Which Events Are Audited for One User

In this example, the audit_control file contains the preselected audit classes for the system:


## audit_control file
…
flags:lo,ss
naflags:lo,na

The audit_user file shows an exception. When the user jdoe uses a profile shell, that use is audited:


## audit_user file
jdoe:pf

The audit preselection mask for jdoe is a combination of the audit_user settings with the audit_control settings. The auditconfig -getaudit command shows the preselection mask for jdoe:


# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656


Example 30–9 Auditing Users Only, Not the System

In this example, the login and role activities of four users only are audited on this system. The audit_control file does not preselect audit classes for the system.


## audit_control file
…
flags:
naflags:

The audit_user file preselects two audit classes for four users, as follows:


## audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

The following audit_control file records unwarranted intrusion. In combination with the audit_user file, this file protects the system more than the first audit_control file in this example.


## audit_control file
…
flags:
naflags:lo
plugin:name=...

ProcedureHow to Add an Audit Class

When you create your own audit class, you can place into it just those audit events that you want to audit for your site. When you add the class on one system, you should copy the change to all systems that are being audited.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

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


    # cp /etc/security/audit_class /etc/security/audit_class.orig
    
  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 letter name of the audit class.

    description

    Defines the descriptive name of the audit class.

    The entry must be unique in the file. Do not use existing audit class masks.


Example 30–10 Creating a New Audit Class

This example creates a class to hold a small set of audit events. The added entry to the audit_class file is as follows:


0x10000000:pf:profile command

The entry creates a new audit class that is called pf. Example 30–11 populates the new audit class.


Troubleshooting

If you have customized the audit_class file, make sure that any modifications to audit_user are consistent with the new audit classes. Errors occur when the audit classes in audit_user are not a subset of the audit_class database.

ProcedureHow to Change an Audit Event's Class Membership

You might want to change an audit event's class membership to reduce the size of an existing audit class, or to place the event in a class of its own. When you reconfigure audit event-class mappings on one system, you should copy the change to all systems that are being audited.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  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 class-list of the events.

    Each entry has the following format:


    number:name:description:class-list
    
    number

    Is the audit event ID.

    name

    Is the name of the audit event.

    description

    Typically, the system call or executable that triggers the creation of an audit record.

    class-list

    Is a comma-separated list of audit classes.


Example 30–11 Mapping Existing Audit Events to a New Class

This example maps an existing audit event to the new class that was created in Example 30–10. In the audit_control file, the binary audit record captures successes and failures of events in the pf class. The syslog audit log contains only failures of events in the pf class.


# grep pf | /etc/security/audit_class
0x10000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-pf


Example 30–12 Auditing the Use of setuid Programs

This example creates a class to hold events that monitor calls to the setuid and setgid programs. The binary audit record captures successes and failures of events in the lo and na classes, and the successes of events in the st class. The syslog audit log contains only successes of events in the st class.


# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st

# vi audit_control
## audit_control file
flags:lo,+st
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,+st

Configuring and Enabling the Audit Service (Task Map)

The following task map points to procedures for configuring and enabling the audit service. The tasks are ordered.

Task 

Description 

For Instructions 

1. (Optional) Change the audit configuration files 

Selects which events, classes, and users require auditing. 

Configuring Audit Files (Task Map)

2. Create audit partitions 

Creates disk space for the audit files, and protects them with file permissions. 

How to Create Partitions for Audit Files

3. Create the audit_warn alias

Defines who should get email warnings when the audit service needs attention. 

How to Configure the audit_warn Email Alias

4. (Optional) Change audit policy 

Defines additional audit data that your site requires. 

How to Configure Audit Policy

5. (Optional) Change audit queue parameters 

Modifies the default queue parameters. 

How to Configure Audit Queue Parameters

6. Configure auditing in non-global zones 

Enable non-global zones to collect auditing records 

Configuring the Audit Service in Zones (Tasks)

7. Enable auditing 

Turns on the audit service. 

How to Enable the Audit Service

When perzone auditing is turned on, enables auditing in a non-global zone.

Example 30–17

8. (Optional) Disable auditing 

Turns off the audit service. 

How to Disable the Audit Service

When perzone auditing is turned on, disables auditing in a non-global zone.

Example 30–22

9. (Optional) Reread auditing configuration changes 

Reads audit configuration changes into the kernel while the auditd daemon is running.

How to Update the Audit Service

Configuring and Enabling the Audit Service (Tasks)

After the configuration files have been set up for your site, you need to set up disk space for your audit files. You also need to set up other attributes of the audit service, and then enable the service. This section also contains procedures to refresh the audit service when you change configuration settings.

When a non-global zone is installed, you can choose to audit the zone exactly as the global zone is being audited. Alternatively, to audit the non-global zone individually, you can modify the audit configuration files in the non-global zone. To customize audit configuration files, see Configuring Audit Files (Task Map).

ProcedureHow to Create Partitions for Audit Files

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. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

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

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

  3. Create a storage pool and a mirror.

    For more information, see What Is ZFS? in Solaris ZFS Administration Guide.


    # zpool create audit-pool mirror slice1 slice2
    

    For example, create the auditf pool from two slices, and mirror them:


    # zpool create auditf mirror c0t4d0 c0t5d0
    

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

  4. Create a mount point for the audit files.


    # zpool create -o mountpoint=/mountpoint /audit-pool/mountpoint
    

    For example, create the /audit mount point:


    # zfs create -o mountpoint=/audit auditf/audit
    
  5. Create audit directories for every set of audit files that is going to be mounted.


    # zfs create auditf/audit/machine1
    # zfs create auditf/audit/machine1/files
    # zfs create auditf/audit/machine2
    # zfs create auditf/audit/machine2/files

    For example, create directories for the noddy and blinken systems:


    # zfs create auditf/audit/noddy
    # zfs create auditf/audit/noddy/files
    # zfs create auditf/audit/blinken
    # zfs create auditf/audit/blinken/files
    
  6. Protect the mount points.

    The following ZFS properties are set to off:


    # zfs set devices=off auditf/audit
    # zfs set exec=off auditf/audit
    # zfs set setuid=off auditf/audit
    
  7. On a file server, define the file systems to be made available to other hosts.


    # zfs set sharenfs=on audit-pool/mountpoint
    

    For example, share the audit pool directory:


    # zfs set sharenfs=on auditf/audit
    

    As a result of sharing the auditf/audit directory, the following directories are shared:


    /audit/noddy
    /audit/noddy/files
    /audit/blinken
    /audit/blinken/files
  8. (Optional) Remove the minimum free space threshold on the audit pool.

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


    # tunefs -m 0 /auditf/audit
    

    For example, tune the audit pool directory:


    # tunefs -m 0 auditf/audit
    
  9. 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 might not be running.

    • If the NFS service is offline, enable the service.


      % svcs \*nfs\*
      disabled       Nov_02   svc:/network/nfs/rquota:default
      offline        Nov_02   svc:/network/nfs/server:default
      # svcadm enable network/nfs/server
      
    • If the NFS service is running, restart the service.


      % svcs \*nfs\*
      online         Nov_02   svc:/network/nfs/client:default
      online         Nov_02   svc:/network/nfs/server:default
      # svcadm restart network/nfs/server
      

    For more information about the NFS service, refer to Setting Up NFS Services in System Administration Guide: Network Services. For information on managing persistent services, see Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration and the smf(5) man page.

ProcedureHow to Configure the audit_warn Email Alias

The audit_warn script generates mail to an email alias that is called audit_warn. To send this mail to a valid email address, you can follow one of the options that are described in Step 2:

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Configure the audit_warn email alias.

    Choose one of the following options:

    • OPTION 1 – Replace the audit_warn email alias with another email account in the audit_warn script.

      Change the email alias in the following line of the script:


      ADDRESS=audit_warn            # standard alias for audit alerts
    • OPTION 2 – Redirect the audit_warn email to another mail account.

      In this case, you would add the audit_warn email 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 email alias:


      audit_warn: root

ProcedureHow to Configure Audit Policy

Audit policy determines the characteristics of the audit records for the local host. When auditing is enabled, the policies that you set by using the auditconfig -setpolicy command determine the audit policy.

You can inspect and change the current audit policy options with the auditconfig command. This command can set a temporary, or active policy. An active policy is a policy that is currently used by the kernel. This command also sets persistent policy, or configured policy. Configured policy is the policy that is restored when you restart the audit service.

  1. Assume a role that includes the Audit Control profile, or become superuser.

    To create a role that includes the Audit Control profile and to assign the role to a user, see Configuring RBAC (Task Map).

  2. Review the audit policy.

    To view the settings, use the auditconfig -getpolicy command:


    $ auditconfig -getpolicy
    
  3. View the available policy options.


    $ auditconfig -lspolicy
    

    Note –

    The perzone and ahlt policy options can be set only in the global zone.


  4. Enable or disable selected audit policy options.


    # auditconfig [ -t ] -setpolicy prefixpolicy
    
    -t

    Optional. Creates a temporary, or active, policy. The policy setting is not restored when you restart the audit service.

    prefix

    A prefix value of + enables the policy option. A prefix value of - disables the policy option.

    policy

    Selects the policy to be enabled or to be disabled.

    A temporary (-t) policy is in effect until the the audit service is restarted, or until the policy is modified by the auditconfig -setpolicy command. Without the -t option, the policy setting persists across restarts of the audit service.

    For a description of each policy option, see Determining Audit Policy.


Example 30–13 Setting the cnt and ahlt Audit Policy Options

In this example, the cnt policy is disabled, and the ahlt policy is enabled. With these settings, system use is halted when the audit partitions are full and an asynchronous event occurs. When a synchronous event occurs, the process that created the thread hangs. These settings are appropriate when security is more important than availability.

The following auditconfig policy commands disable the cnt policy option and enable the ahlt policy option:


# auditconfig -setpolicy -cnt
# auditconfig -setpolicy +ahlt

These settings persist until you change them.



Example 30–14 Setting an Audit Policy Temporarily

In this example, the audit service is running and the ahlt audit policy is configured. The administrator adds the seq audit policy to the active policy, but does not configure the audit service to use the seq audit policy permanently. The seq policy is useful for debugging the audit service when audit records are corrupted, or when records are being dropped.

The + prefix adds the seq option to the audit policy, rather than replaces the current audit policy with seq. The -t option makes the policy active in the kernel.


$ auditconfig -setpolicy none
$ auditconfig -getpolicy
  configured audit policies = none
  active audit policies = none
$ auditconfig -setpolicy ahlt
$ auditconfig -getpolicy
  configured audit policies = ahlt
  active audit policies = ahlt
$ auditconfig -t -setpolicy +seq
  configured audit policies = ahlt,seq
  active audit policies = ahlt,seq

The administrator unsets the seq policy when the debugging is completed:


$ auditconfig -setpolicy -seq
$ auditconfig -getpolicy
  configured audit policies = ahlt
  active audit policies = ahlt


Example 30–15 Setting the perzone Audit Policy

In this example, the perzone audit policy is set in the global zone. When a zone boots, the non-global zone collects audit records according to the audit configuration settings in its zone. The perzone policy setting is stored as a property of the audit service, so it is in effect during the session and when the audit service is restarted.


$ auditconfig -setpolicy none
$ auditconfig -getpolicy
  configured audit policies = none
  active audit policies = none
$ auditconfig -setpolicy +perzone
$ auditconfig -getpolicy
  configured audit policies = perzone
  active audit policies = perzone

ProcedureHow to Configure Audit Queue Parameters

The audit service provides default values for audit queue parameters. You can inspect and set these values with the auditconfig command.

The auditconfig command can set a temporary, or active, value. This value is used by the kernel, but it is not set as a property of the audit service. This command also sets persistent, or configured, values. Configured values are the values that are restored when you restart the audit service.

  1. Assume a role that includes the Audit Control profile, or become superuser.

    To create a role that includes the Audit Control profile and to assign the role to a user, see Configuring RBAC (Task Map).

  2. Review the audit queue parameter values.

    To view the values, use the auditconfig -getqctrl command.


    $ auditconfig -getqctrl
    no configured audit queue lowater mark
    no configured ...

    The string no configured indicates that the system is using the default settings. For a description of the audit queue parameters, see the auditconfig(1M) man page.

  3. Modify selected audit queue parameters.

    • To modify all audit queue parameters, use the -setqctrl option.


      # auditconfig [ -t ]-setqctrl hiwater lowater bufsz interval
      
    • To modify a specific audit queue parameter, use the specific option, one of -setqbufsz, -setqdelay, -setqlowater, and -setqhiwater.


      # auditconfig [ -t ]-setq* value
      
    -t

    Optional. Sets a temporary, or active, value. This value is not set as a property value of the audit service.

    hiwater ...

    Are audit queue parameters.

    value

    Is a value for the audit queue parameter.

    A temporary (-t) or active value is in effect until the audit service is restarted, or until the value is modified by the auditconfig [-t] -setq* command. Without the -t option, the queue parameter value is stored as a property value of the audit service.


Example 30–16 Configuring Audit Queue Parameters

In this example, the administrator configures the audit queue's write buffer size and wakeup interval. The administrator tunes these parameters differently in the active configuration by using the -t option.


# auditconfig -getqctrl
  no configured audit queue hiwater mark
  no configured audit queue lowater mark
  no configured audit queue buffer size
  no configured audit queue delay
  active audit queue hiwater mark (records) = 110
  active audit queue lowater mark (records) = 30
  active audit queue buffer size (bytes) = 8192
  active audit queue delay (ticks) = 20
# auditconfig -setqbufsz 8192
# auditconfig -setqdelay 20
# auditconfig -t -setqbufsz 12288
# auditconfig -t -setqdelay 25
# auditconfig -getqctrl
  no configured audit queue lowater mark
  no configured audit queue hiwater mark
  configured audit queue buffer size (bytes) = 8192
  configured audit queue delay (ticks) = 20
  active audit queue hiwater mark (records) = 100
  active audit queue lowater mark (records) = 10
  active audit queue buffer size (bytes) = 12288
  active audit queue delay (ticks) = 25

The administrator resets the parameters to their default values by setting them to zero.


auditconfig -setqbufsz 0
  auditon(2) failed.
  error: Invalid argument(22)
# auditconfig -setqdelay 0
  auditon(2) failed.
  error: Invalid argument(22)
# auditconfig -getqctrl
  no configured audit queue hiwater mark
  no configured audit queue lowater mark
  no configured audit queue buffer size
  no configured audit queue delay
  active audit queue hiwater mark (records) = 110
  active audit queue lowater mark (records) = 30
  active audit queue buffer size (bytes) = 12288
  active audit queue delay (ticks) = 25

ProcedureHow to Enable the Audit Service

This procedure enables the audit service for all zones. To start the audit daemon in a non-global zone, see Example 30–17.

When auditing is configured securely, the system is in single-user mode until auditing is enabled. You can also enable auditing in multiuser mode.

Before You Begin

You should perform this procedure as superuser after completing the following tasks:

  1. Run the script that enables the audit service.

    Go to the /etc/security directory, and execute the bsmconv script there.


    # cd /etc/security
    # ./bsmconv
    This script is used to enable the Basic Security Module (BSM).
    Shall we continue with the conversion now? [y/n] y
    bsmconv: INFO: checking startup file.
    bsmconv: INFO: turning on audit module.
    bsmconv: INFO: initializing device allocation.
    
    The Basic Security Module is ready.
    If there were any errors, please fix them now.
    Configure BSM by editing files located in /etc/security.
    Reboot this system now to come up with BSM enabled.

    For the effects of the script, see the bsmconv(1M) man page.

  2. Reboot the system.


    # reboot
    

    The auditd daemon starts the audit service when the system enters multiuser mode. The FMRI for the audit service is svc:/system/auditd:default.

    Another effect of the script is to turn on device allocation. To configure device allocation, see Managing Device Allocation (Task Map).


Example 30–17 Enabling Auditing in a Non-Global Zone

In the following example, the global zone administrator turned on perzone policy after auditing was enabled in the global zone and after the non-global zone had booted. The zone administrator of the non-global zone has configured the audit files for the zone, and then starts the audit daemon in the zone.


zone1# svcadm enable svc:/system/auditd

ProcedureHow to Disable the Audit Service

If the audit service is no longer required at some point, this procedure returns the system to the system state before auditing was enabled. If non-global zones are being audited, their audit service is also disabled.


Caution – Caution –

This command also disables device allocation. Do not run this command if you want to be able to allocate devices. To disable auditing and retain device allocation, see Example 30–18.


  1. Become superuser and bring the system into single-user mode.


    % su
    Password: <Type root password>
    # init S
    

    For more information, see the init(1M) man page.

  2. Run the script to disable auditing.

    Change to the /etc/security directory, and execute the bsmunconv script.


    # cd /etc/security
    # ./bsmunconv
    

    Another effect of the script is to disable device allocation.

    For information on the full effect of the bsmunconv script, see the bsmconv(1M) man page.

  3. Bring the system into multiuser mode.


    # init 6
    

Example 30–18 Disabling Auditing and Keeping Device Allocation

In this example, the audit service stops collecting records, but device allocation continues to work. All values from the flags, naflags, and plugin entries in the audit_control file are removed, as are all user entries in the audit_user file.


## audit_control file
flags:
naflags:

## audit_user file

The auditd daemon runs, but no audit records are kept.



Example 30–19 Disabling Auditing on a Per-Zone Basis

In this example, the audit service stops running in zone1 where the audit service is disabled. Device allocation continues to work. When this command is run in the global zone, and the perzone audit policy is not set, auditing is disabled for all zones, not just the global zone.


zone1 # audit -t

ProcedureHow to Update the Audit Service

This procedure restarts the auditd daemon when you have made changes to audit configuration files after the daemon has been running.

  1. Assume a role that includes the Audit Control rights profile, or become superuser.

    To create a role that includes the Audit Control rights profile and assign the role to a user, see Configuring RBAC (Task Map).

  2. Choose the appropriate command.

    • If you modify the naflags line in the audit_control file, change the kernel mask for nonattributable events.


      $ /usr/sbin/auditconfig -aconf
      

      You can also reboot.

    • If you modify other lines in the audit_control file, reread the audit_control file.

      The audit daemon stores information from the audit_control file internally. To use the new information, either reboot the system or instruct the audit daemon to read the modified file.


      $ /usr/sbin/audit -s
      

      Note –

      Audit records are generated based on the audit preselection mask that is associated with each process. Executing audit -s does not change the masks in existing processes. To change the preselection mask for an existing process, you must restart the process. You can also reboot.


      The audit -s command causes the audit daemon to re-read the directory and minfree values from the audit_control file. The command changes the generation of the preselection mask for processes spawned by subsequent logins.

    • If you modify the audit_event file or the audit_class file while the audit daemon is running, refresh the audit service.

      Read the modified event-class mappings into the system, and ensure that each user who uses the machine is correctly audited.


      $ auditconfig -conf
      $ auditconfig -setumask auid classes
      
      auid

      Is the user ID.

      classes

      Are the preselected audit classes.

      For an example, see How to Modify a User's Preselection Mask.


Example 30–20 Restarting the Audit Daemon

In this example, the system is brought down to single-user mode, then back up to multiuser mode. When the system is brought into multiuser mode, modified audit configuration files are read into the system.


# init S
# init 6

Configuring the Audit Service in Zones (Tasks)

The audit service audits the entire system, including audit events in zones. A system that has installed non-global zones can audit all zones identically, or can control auditing per zone. For background, see Auditing on a System With Zones. To plan, see How to Plan Auditing in Zones.

ProcedureHow to Configure All Zones Identically for Auditing

This procedure enables audits every zone identically. This method requires the least computer overhead and administrative resources.

  1. Configure the global zone for auditing.

    1. Complete the tasks in Configuring Audit Files (Task Map).

    2. Complete the tasks in Configuring and Enabling the Audit Service (Task Map), with the following exceptions.

      • Do not enable perzone audit policy.

      • Do not enable the audit service. You enable the audit service after you have configured the non-global zones for auditing.

  2. Copy the audit configuration files from the global zone to every non-global zone.

    Copy any of the following files that you have edited: audit_class, audit_control, audit_event, audit_user. Do not copy audit_warn. You do not have to copy files that you have not edited.

    You have two options. As superuser, you can copy the files, or loopback mount the files. The non-global zone must be running.

    • Copy the files.

      1. From the global zone, list the /etc/security directory in the non-global zone.


        # ls /zone/zonename/etc/security/
      2. Copy the audit configuration files to the zone's /etc/security directory.


        # cp /etc/security/audit-file /zone/zonename/etc/security/audit-file
        

        Later, if you modify an audit configuration file in the global zone, you re-copy the file to the non-global zones.

    • Loopback mount the configuration files.

      1. From the global zone, halt the non-global zone.


        # zoneadm -z non-global-zone halt
      2. Create a read-only loopback mount for every audit configuration file that you modified in the global zone.


        # zonecfg -z non-global-zone
         add fs
            set special=/etc/security/audit-file
            set dir=/etc/security/audit-file
            set type=lofs
            add options [ro,nodevices,nosetuid]
            end
         exit
      3. To make the changes effective, boot the non-global zone.


        # zoneadm -z non-global-zone boot

        You can also reboot the system.

        Later, if you modify an audit configuration file in the global zone, you reboot the system to refresh the loopback-mounted files in the non-global zones.


Example 30–21 Loopback Mounting Audit Configuration Files

In this example, the system administrator has modified the audit_class, audit_event, audit_control, audit_user, and audit_warn files.

The audit_warn file is read in the global zone only, so does not have to be loopback mounted into the non-global zones.

On this system, machine1, the administrator has created two non-global zones, machine1–webserver and machine1–appserver. The administrator has finished customizing the audit configuration files. If the administrator later modifies the files, the system will be rebooted to make the changes effective.


# zoneadm -z machine1-webserver halt
# zoneadm -z machine1-appserver halt
# zonecfg -z machine1-webserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_event
    set dir=/etc/security/audit_event
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_control
    set dir=/etc/security/audit_control
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end 
add fs
    set special=/etc/security/audit_user
    set dir=/etc/security/audit_user
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 exit
# zonecfg -z machine1-appserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
...
 exit

When the zones are rebooted, the audit configuration files are read-only in the zones.


ProcedureHow to Configure Per-Zone Auditing

This procedure enables separate zone administrators to control the audit service in their zone. For the complete list of policy options, see the auditconfig(1M) man page.

  1. In the global zone, configure auditing, but do not enable the audit service.

    1. Complete the tasks in Configuring Audit Files (Task Map).

    2. Complete the tasks in Configuring and Enabling the Audit Service (Task Map), with the following exceptions.

      • Add the perzone audit policy. For an example, see Example 30–15.

      • Do not enable the audit service. You enable the audit service after the non-global zones are configured for auditing.

  2. In each non-global zone, configure the audit files.


    Note –

    If you are planning to disable auditing in the non-global zone, you can skip this step. To disable auditing, see Example 30–22.


    1. Complete the tasks in Configuring Audit Files (Task Map).

    2. Follow the procedures that are described in Configuring and Enabling the Audit Service (Task Map).

    3. Do not configure system-wide audit settings.

      Specifically, do not add the perzone or ahlt policy to the non-global zone. And do not run the bsmconv command from the non-global zone.

    4. Enable auditing in your zone.

      When the global zone reboots after auditing is configured, auditing is automatically enabled in your zone.

      If the global zone administrator activates the perzone audit policy after the system is booted, individual zone administrators must enable auditing. For details, see Example 30–17.

  3. In the global zone, enable the audit service.

    For the procedure, see How to Enable the Audit Service.


Example 30–22 Disabling Auditing in a Non-Global Zone

This example works if the global zone has set the perzone audit policy. The zone administrator of the noaudit zone disables auditing for that zone. Because the administrator planned to disable auditing, she did not edit the audit configuration files.


noauditzone # svcadm disable svc:/system/auditd

Managing Audit Records (Task Map)

The following task map points to procedures for selecting, analyzing, and managing audit records.

Task 

Description 

For Instructions 

Display the formats of audit records 

Shows the kind of information that is collected for an audit event, and the order in which the information is presented. 

How to Display Audit Record Formats

Merge audit records 

Combines audit files from several machines into one audit trail. 

How to Merge Audit Files From the Audit Trail

Select records to examine 

Selects particular events for study. 

How to Select Audit Events From the Audit Trail

Display audit records 

Enables you to view binary audit records. 

How to View the Contents of Binary Audit Files

Clean up incorrectly named audit files 

Provides an end timestamp to audit files that were inadvertently left open by the audit service. 

How to Clean Up a not_terminated Audit File

Prevent audit trail overflow 

Prevents the audit file systems from becoming full. 

How to Prevent Audit Trail Overflow

Managing Audit Records

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.

ProcedureHow to Display Audit Record Formats

To write scripts that can find the audit data that you want, you need to know the order of tokens in an audit event. The auditrecord command displays the audit event number, audit class, selection mask, and record format of an audit event.

  1. Put the format of all audit event records in an HTML file.

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


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

    When you display the *html file in a browser, use the browser's Find tool to find specific records.

    For more information, see the auditrecord(1M) man page.


Example 30–23 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. The login programs include rlogin, telnet, newgrp, role login to the Solaris Management Console, and Solaris Secure Shell.


% auditrecord -p login
terminal login   program     /usr/sbin/login      See login(1)           
   /usr/dt/bin/dtlogin  See dtlogin   event ID    6152                 AUE_login
  class       lo                   (0x00001000)       header       subject
      text                         error message or "successful login"   
   return 
login: logout
  program     various              See login(1)
  event ID    6153                 AUE_logout
…

newgrp
  program     newgrp               See newgrp login
  event ID    6212                 AUE_newgrp_login
…

rlogin
  program     /usr/sbin/login      See login(1) - rlogin
  event ID    6155                 AUE_rlogin
…

SMC: role login
  program     SMC server           See role login
  event ID    6173                 AUE_role_login
…

/usr/lib/ssh/sshd
  program     /usr/lib/ssh/sshd    See login - ssh
  event ID    6172                 AUE_ssh
…

telnet login
  program     /usr/sbin/login      See login(1) - telnet
  event ID    6154                 AUE_telnet
  …


Example 30–24 Displaying the Audit Record Formats of an Audit Class

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


% auditrecord -c fd

rmdir
  system call rmdir                See rmdir(2)
  event ID    48                   AUE_RMDIR
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      [use_of_privilege]
      return

unlink
  system call unlink               See unlink(2)
  event ID    6                    AUE_UNLINK
  …

unlinkat
  system call unlinkat             See openat(2)
  event ID    286                  AUE_UNLINKAT
  …

ProcedureHow to Merge Audit Files From the Audit Trail

By merging all audit files in all the audit directories, you can analyze the contents of the entire audit trail. The auditreduce command merges all the records from its input files into a single output file. The input files can then be deleted. When the output file is placed in a directory that is named /etc/security/auditserver-name/files, the auditreduce command can find the output file without your specifying the full path.


Note –

This procedure applies only to binary audit records.


  1. Assume a role that includes the Audit Review profile, or become superuser.

    The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

  2. Create a directory for storing merged audit files.


    # mkdir audit-trail-directory
    
  3. Limit access to the directory.


    # chmod 700 audit-trail-directory
    # ls -la audit-trail-directory
    drwx------   3 root     sys          512 May 12 11:47 .
    drwxr-xr-x   4 root     sys         1024 May 12 12:47 ..
  4. Merge the audit records in the audit trail.

    Change directories to the audit-trail-directory and merge the audit records into a file with a named suffix. All directories that are listed in the dir lines of the audit_control file on the local system are merged.


    # cd audit-trail-directory
    # auditreduce -Uppercase-option -O suffix
    

    The uppercase options to the auditreduce command manipulate files in the audit trail. The uppercase options include the following:

    -A

    Selects all of the files in the audit trail.

    -C

    Selects complete files only. This option ignores files with the suffix not_terminated.

    -M

    Selects files with a particular suffix. The suffix can be a machine name, or it can be a suffix that you have specified for a summary file.

    -O

    Creates an audit file with 14-character timestamps for both the start time and the end time, with the suffix suffix in the current directory.


Example 30–25 Copying Audit Files to a Summary File

In the following example, the System Administrator role, sysadmin, copies all files from the audit trail into a merged file.


$ whoami
sysadmin
$ mkdir /var/audit/audit_summary.dir
$ chmod 700 /var/audit/audit_summary.dir
$ cd /var/audit/audit_summary.dir
$ auditreduce -A -O All
$ ls *All
20030827183214.20030827215318.All

In the following example, only complete files are copied from the audit trail into a merged file.


$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O Complete
$ ls *Complete
20030827183214.20030827214217.Complete

In the following example, only complete files are copied from the example1 machine into a merged file.


$ cd /var/audit/audit_summary.dir
$ auditreduce -M example1 -O example1summ
$ ls *summ
20030827183214.20030827214217.example1summ


Example 30–26 Moving Audit Files to a Summary File

The -D option to the auditreduce command deletes an audit file when you copy it to another location. In the following example, the complete audit files from one system are copied to the summary directory for later examination.


$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O daily_example1 -D example1
$ ls *example1
20030827183214.20030827214217.daily_example1

The audit files from the example1 system that were the input to the *daily_example1 file are removed when this command successfully completes.


ProcedureHow to Select Audit Events From the Audit Trail

You can filter audit records for examination. For the complete list of filtering options, see the auditreduce(1M) man page.

  1. Assume a role that includes the Audit Review profile, or become superuser.

    The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

  2. Select the kinds of records that you want from the audit trail, or from a specified audit file.


    auditreduce -lowercase-option argument [optional-file]
    argument

    Specific argument that a lowercase option requires. For example, the -c option requires an argument of an audit class, such as ua.

    -d

    Selects all of the events on a particular date. The date format for argument is yyymmdd. Other date options, -b and -a, select events before and after a particular date.

    -u

    Selects all of the events attributable to a particular user. The argument is a user name. Another user option, -e, selects all of the events attributable to an effective user ID.

    -c

    Selects all of the events in a preselected audit class. The argument is an audit class name.

    -m

    Selects all of the instances of a particular audit event. The argument is an audit event.

    optional-file

    Is the name of an audit file.


Example 30–27 Combining and Reducing Audit Files

The auditreduce 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 media.


# cd /var/audit/audit_summary.dir
# auditreduce -O lo.summary -b 20030827 -c lo; compress *lo.summary


Example 30–28 Copying na Audit Records to a Summary File

In this example, all the records of nonattributable audit events in the audit trail are collected into one file.


$ whoami
sysadmin
$ cd /var/audit/audit_summary.dir
$ auditreduce -c na -O nasumm
$ ls *nasumm
20030827183214.20030827215318.nasumm

The merged nasumm audit file is time stamped with the beginning and ending date of the na records.



Example 30–29 Finding Audit Events in a Specified Audit File

You can select audit files manually to search just the named set of files. For example, you can further process the *nasumm file in the previous example to find system boot events. To do so, you would specify the file name as the final argument to the auditreduce command.


$ auditreduce -m 113 -O systemboot 20030827183214.20030827215318.nasumm
20030827183214.20030827183214.systemboot

The 20030827183214.20030827183214.systemboot file contains only system boot audit events.



Example 30–30 Copying One User's Audit Records to a Summary File

In this example, the records in the audit trail that contain the name of a particular user are merged. The -e option finds the effective user. The -u option finds the audit user.


$ cd /var/audit/audit_summary.dir
$ auditreduce -e tamiko -O tamiko

You can look for specific events in this file. In the following example, what time the user logged in and out on Sept 7, 2003, your time, is checked. Only those files with the user's name as the file suffix are checked. The short form of the date is yyyymmdd.


# auditreduce -M tamiko -O tamikolo -d 20030907 -u tamiko -c lo


Example 30–31 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 20030827 -O /var/audit/audit_summary.dir/logins
# ls /var/audit/audit_summary.dir/*logins
/var/audit/audit_summary.dir/20030827183936.20030827232326.logins

ProcedureHow to View the Contents of Binary Audit Files

The praudit command enables you to view the contents of binary audit files. You can pipe the output from the auditreduce command, or you can read a particular audit file. The -x option is useful for further processing.

  1. Assume a role that includes the Audit Review profile, or become superuser.

    The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

  2. Use one of the following praudit commands to produce the output that is best for your purposes.

    The following examples show praudit output from the same audit event. Audit policy has been set to include the sequence and trailer tokens.

    • The praudit -s command displays audit records in a short format, one token per line. Use the -l option to place each record on one line.


      $ auditreduce -c lo | praudit -s
      header,101,2,AUE_rlogin,,example1,2003-10-13 11:23:31.050 -07:00
      subject,jdoe,jdoe,staff,jdoe,staff,749,749,195 1234 server1
      text,successful login 
      return,success,0 
      sequence,1298
    • The praudit -r command displays audit records in their raw format, one token per line. Use the -l option to place each record on one line.


      $ auditreduce -c lo | praudit -r
      21,101,2,6155,0x0000,192.168.60.83,1062021202,64408258
      36,2026700,2026700,10,2026700,10,749,749,195 1234 192.168.60.17
      40,successful login
      39,0,0
      47,1298
    • The praudit -x command displays audit records in XML format, one token per line. Use the -l option to place the XML output for one record on one line.


      $ auditreduce -c lo | praudit -x
      <record version="2" event="login - rlogin" host="example1" 
      time="Wed Aug 27 14:53:22 PDT 2003" msec="64">
      <subject audit-uid="jdoe" uid="jdoe" gid="staff" ruid="jdoe" 
      rgid="staff" pid="749" sid="749" tid="195 1234 server1"/>
      <text>successful login</text>
      <return errval="success" retval="0"/>
      <sequence seq-num="1298"/>
      
      </record>

Example 30–32 Printing the Entire Audit Trail

With a pipe to the lp command, the output for the entire audit trail goes to the printer. The printer should have limited access.


# auditreduce | praudit | lp -d example.protected.printer


Example 30–33 Viewing a Specific Audit File

In this example, a summary login file is examined in a terminal window.


# cd /var/audit/audit_summary.dir/logins
# praudit 20030827183936.20030827232326.logins | more


Example 30–34 Putting Audit Records in XML Format

In this example, the audit records are converted to XML format.


# praudit -x 20030827183214.20030827215318.logins > 20030827.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.


Troubleshooting

A message similar to the following indicates that you do not have enough privilege to use the praudit command:

praudit: Can't assign 20090408164827.20090408171614.example1 to stdin.

ProcedureHow to Clean Up a not_terminated Audit File

Occasionally, an audit daemon exits 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 timestamp, even though the file is no longer used for audit records. Use the auditreduce -O command to give the file the correct timestamp.

  1. List the files with the not_terminated string on your audit file system in order of creation.


    # ls -R1t audit-directory*/files/* | grep not_terminated
    -R

    Lists files in subdirectories.

    -t

    Lists files from most recent to oldest.

    -1

    Lists the files in one column.

  2. Clean up the old not_terminated file.

    Specify the name of the old file to the auditreduce -O command.


    # auditreduce -O system-name old-not-terminated-file
    
  3. Remove the old not_terminated file.


    # rm system-name old-not-terminated-file
    

Example 30–35 Cleaning Up Closed not_terminated Audit Files

In the following example, not_terminated files are found, renamed, then the originals are removed.


ls -R1t */files/* | grep not_terminated
…/egret.1/20030908162220.not_terminated.egret
…/egret.1/20030827215359.not_terminated.egret
# cd */files/egret.1
# auditreduce -O egret 20030908162220.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Input (old) audit file
20030827215359.not_terminated.egret
# rm 20030827215359.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Cleaned up audit file

The start timestamp on the new file reflects the time of the first audit event in the not_terminated file. The end timestamp reflects the time of the last audit event in the file.


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

    Archive audit files by backing up the files to offline media. You can also move the files to an archive file system.

    If you are collecting text audit logs with the syslog utility, archive the text logs. For more information, see the logadm(1M) man page.

  2. Set up a schedule to delete the archived audit files from the audit file system.

  3. Save and store auxiliary information.

    Archive information that is necessary to interpret audit records along with the audit trail.

  4. Keep records of which audit files have been archived.

  5. Store the archived media 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 contain only records for specified types of audit events. To extract summary files, see Example 30–27 and Example 30–31.

Troubleshooting Solaris Auditing (Tasks)

This section covers various Solaris auditing error messages, preferences, and the auditing that is provided by other tools. These procedures can help you record the audit events that you require at your site.

Troubleshooting Solaris Auditing (Task Map)

The following task map points to procedures for troubleshooting Solaris auditing.

Problem 

Solution 

For Instructions 

Why are audit files not being created when I have configured auditing? 

Troubleshoot the audit daemon and audit configuration files. 

How to Determine That Solaris Auditing Is Running

How can I reduce the amount of audit information that is being collected? 

Audit just the events that you want to audit. 

How to Lessen the Volume of Audit Records That Are Produced

How can I audit everything that a user does on the system? 

Audit one or more users for every command. 

How to Audit All Commands by Users

How can I change the audit events that are being recorded and have the change affect existing sessions? 

Update a user's preselection mask 

How to Modify a User's Preselection Mask

How can I locate modifications to particular files? 

Audit file modifications, then use the auditreduce command to find particular files.

How to Find Audit Records of Changes to Specific Files

How can I reduce the size of my audit files? 

Limit the size of the binary audit file. 

How to Limit the Size of Binary Audit Files

How can I remove audit events from the audit_event file?

Update the audit_event file.

How to Prevent the Auditing of Certain Events

How can I audit all logins to a Solaris system? 

Audit logins from any system. 

How to Audit Logins From Other OSes

Why are auditing records not being kept for my FTP transfers? 

Use the appropriate auditing tool for utilities that generate their own logs. 

How to Audit FTP and SFTP File Transfers

ProcedureHow to Determine That Solaris Auditing Is Running

If you believe that auditing has been activated, but no audit records are in your primary audit directory, try the following.

  1. Determine that auditing is running.

    • Verify that the c2audit kernel module is loaded.


      # modinfo | grep c2audit
      

      No listing indicates that auditing is not running. The following listing indicates that auditing is running:


      40  132ce90  14230 186   1  c2audit (C2 system call)
    • Verify that the audit daemon is running.

      Verify the status of the auditd service. The following listing indicates that auditing is not running:


      # svcs -x auditd
      svc:/system/auditd:default (Solaris audit daemon)
       State: disabled since Fri Aug 14 19:02:35 2009
      Reason: Disabled by an administrator.
         See: http://sun.com/msg/SMF-8000-05
         See: auditd(1M)
         See: audit(1M)
      Impact: This service is not running.

      The following listing indicates that the audit service is running:


      # svcs auditd
      STATE          STIME    FMRI
      online         10:10:10 svc:/system/auditd:default
    • Verify the current audit condition.

      The following listing indicates that auditing is not running:


      # auditconfig -getcond
      auditconfig: auditon(2) failed.
      auditconfig: error = Operation not supported(48)

      The following listing indicates that auditing is running:


      # auditconfig -getcond
      audit condition = auditing

    If the audit service is not running, enable it. For the procedure, see How to Enable the Audit Service.

  2. Verify the syntax of the audit_control file.


    # audit -v /etc/security/audit_control
    audit: audit_control must have either a valid "dir:" entry 
    or a valid "plugin:" entry with "p_dir:" specified.

    Correct the errors. The message syntax ok indicates that the file is syntactically correct.

  3. Verify that the audit_control file has valid values for the flags and naflags keywords.


    # grep flags /etc/security/audit_control
    flags:lo
    naflags:na,lp
    

    Supply valid values if the audit_control file has invalid values. In the preceding example, lp is an invalid class.

  4. Verify that the audit_user file has valid values for every user.


    # tail audit_user
    ...
    # User Level Audit User File
    #
    # File Format
    #
    #	username:always:never
    #
    root:lo:no
    admin:lp:no

    Supply valid values if the audit_user file contains invalid values. In the preceding example, lp is an invalid class.

  5. If you created a customized audit class, verify that you assigned events to the class.

    For example, the following audit_control file contains a class that Sun did not deliver:


    # grep flags /etc/security/audit_control
    flags:lo,pf
    naflags:na,lo

    For a description of creating the pf class, see How to Add an Audit Class.

    1. Verify that the class is defined in the audit_class file.

      The audit class mask must be unique.


      # grep pf /etc/security/audit_class
      0x10000000:pf:profile command

      If the class is not defined, define it. Otherwise, remove the class from the audit_control and audit_user files.

    2. Verify that events have been assigned to the class.


      # grep pf /etc/security/audit_event
      6180:AUE_prof_cmd:profile command:ua,as,pf
      

      If events are not assigned to the class, assign the appropriate events to this class.

  6. If the previous steps did not indicate a problem, review the system log files, /var/adm/messages and /var/log/syslog.

    1. Locate and fix the problems.

    2. Then, if the audit service is running, restart it.


      # audit -s
      
    3. If the audit service is not running, enable it.

      For the procedure, see How to Enable the Audit Service.

ProcedureHow to Lessen the Volume of Audit Records That Are Produced

After you have determined which events must be audited at your site, use the following suggestions to create manageable audit files.

  1. Use the default audit policy.

    Specifically, avoid adding events and audit tokens to the audit trail. The following policies affect the size of the audit trail.

    • arge policy – Adds environment variables to exec audit events.

    • argv policy – Adds command parameters to exec audit events.

    • public policy – If file events are being audited, adds an event to the audit trail every time an auditable event happens to a public file. File classes include fa, fc, fd, fm, fr, fw, and cl. For the definition of a public file, see Audit Terminology and Concepts.

    • path policy – Adds a path token to audit events that include an optional path token.

    • group policy – Adds a group token to audit events that include an optional newgroups token.

    • seq policy – Adds a sequence token to every audit event.

    • trail policy – Adds a trailer token to every audit event.

    • windata_down policy – On a system that is configured with Trusted Extensions, adds events when information in a labeled window is downgraded.

    • windata_up policy – On a system that is configured with Trusted Extensions, adds events when information in a labeled window is upgraded.

    • zonename policy – Adds the zone name to every audit event. If the global zone is the only configured zone, adds zone, global to every audit event.

    The following audit record shows the use of the ls command. The ex class is being audited and the default policy is in use:


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
    path,/usr/bin/ls
    subject,jdoe,root,root,root,root,1401,737,0 0 mach1
    return,success,0

    The following is the same record when all policies are turned on:


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
    path,/usr/bin/ls
    attribute,100555,root,bin,136,432,0
    exec_args,1,ls
    exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,PATH=/u
    sr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
    path,/lib/ld.so.1
    attribute,100755,root,bin,136,4289,0
    subject,jdoe,root,root,root,root,1401,737,0 0 mach1
    group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon
    return,success,0
    zone,global
    sequence,313540
    trailer,375
  2. Use the audit_syslog.so plugin to send some audit events to syslog.

    This strategy works only if you are not required to keep binary records of the audit events that you send to the syslog logs. By using the auditreduce command, you can then strip the binary files of these records, thus reducing the size of the binary files.

  3. Use the audit_user file to audit events for specific users and roles.

    Reduce the amount of auditing for all users by reducing the number of audit classes in the audit_control file. In the audit_user file, add audit classes for specific users and roles.

  4. Create your own customized audit class.

    You can create audit classes at your site. Into these classes, put all the audit events that you need to monitor. For the procedure, see How to Add an Audit Class.


    Note –

    If you modify existing audit class assignments, your modifications might be lost when you upgrade to a newer version of the Solaris OS. Carefully review the install logs.


ProcedureHow to Audit All Commands by Users

As part of site security policy, some sites require audit records of all commands that are run by the root user or by administrative roles. Some sites also require audit records of all commands that are run by users.

  1. Audit the lo and ex classes.

    The ex class audits all calls to the exec() and execve() functions. The lo class audits logins, logouts, and screen locks. The following ouput lists all the events in the ex and lo classes.


    7:AUE_EXEC:exec(2):ps,ex
    23:AUE_EXECVE:execve(2):ps,ex
    ...
    6152:AUE_login:login - local:lo
    6153:AUE_logout:logout:lo
    6154:AUE_telnet:login - telnet:lo
    6155:AUE_rlogin:login - rlogin:lo
    6158:AUE_rshd:rsh access:lo
    6159:AUE_su:su:lo
    6162:AUE_rexecd:rexecd:lo
    6163:AUE_passwd:passwd:lo
    6164:AUE_rexd:rexd:lo
    6165:AUE_ftpd:ftp access:lo
    6171:AUE_ftpd_logout:ftp logout:lo
    6172:AUE_ssh:login - ssh:lo
    6173:AUE_role_login:role login:lo
    6212:AUE_newgrp_login:newgrp login:lo
    6213:AUE_admin_authenticate:admin login:lo
    6221:AUE_screenlock:screenlock - lock:lo
    6222:AUE_screenunlock:screenlock - unlock:lo
    6227:AUE_zlogin:login - zlogin:lo
    • To audit these classes for administrators, modify the audit_user file.

      In the following example, the site has created three roles, sysadm, auditadm, and netadm. These roles and the root account are audited for the exec and lo classes:


      ## audit_user file
      root:lo,ex:no
      sysadm:lo,ex:no
      auditadm:lo,ex:no
      netadm:lo,ex:no
    • To audit the lo class for non-attributable events, modify the audit_control file.


      ## audit_control file
      ...
      naflags:lo
      ...
    • To audit these classes for all users, modify the audit_control file.


      ## audit_control file
      flags:lo,ex
      naflags:lo
      ...

      The output appears similar to the following:


      header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
      path,/usr/bin/ls
      subject,jdoe,root,root,root,root,1401,737,0 0 mach1
      return,success,0
  2. To record the arguments to commands, set the argv policy.


    # auditconfig -setpolicy +argv
    

    The exec_args token records the command arguments:


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
    path,/usr/bin/ls
    exec_args,1,ls
    subject,jdoe,root,root,root,root,1401,737,0 0 mach1
    return,success,0
  3. To record the environment in which the command is run, set the arge policy.


    # auditconfig -setpolicy +arge
    

    The exec_env token records the command environment:


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
    path,/usr/bin/ls
    exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
      PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
    subject,jdoe,root,root,root,root,1401,737,0 0 mach1
    return,success,0
  4. To record the arguments and the command environment, set both policies.


    # auditconfig -setpolicy +argv
    

    The output appears similar to the following:


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
    path,/usr/bin/ls
    exec_args,1,ls
    exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
      PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
    subject,jdoe,root,root,root,root,1401,737,0 0 mach1
    return,success,0

ProcedureHow to Find Audit Records of Changes to Specific Files

If your goal is to log file writes against a limited number of files, such as /etc/passwd and the files in the /etc/default directory, you use the auditreduce command to locate the files.

  1. Audit the fw class.

    Adding the class to the audit_user file generates fewer records than adding the class to the audit_control file.

    • Add the fw class to the audit_user file.


      ## audit_user file
      root:fw:no
      sysadm:fw:no
      auditadm:fw:no
      netadm:fw:no
    • Add the fw class to the audit_control file.


      ## audit_control file
      flags:lo,fw
      ...
  2. To find the audit records for specific files, use the auditreduce command.


    # /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg
    

    The auditreduce command searches the audit trail for all instances of the file argument. The command creates a binary file with the suffix filechg which contains all records that include the pathnames of the files of interest. See the auditreduce(1M) man page for the syntax of the -o file=pathname option.

  3. To read the filechg file, use the praudit command.


    # /usr/sbin/praudit *filechg
    

ProcedureHow to Modify a User's Preselection Mask

If you modify the audit_control or audit_user file, the preselection mask of users who are already logged in does not change. You must force the preselection mask to change.

Before You Begin

You enabled auditing, users logged in, and then you changed the value of flags or naflags in the audit_control file. You want the users who are already logged in to be audited for these newly selected audit classes.

  1. Update the preselection mask of users who are already logged in.

    You have two options. You can terminate the existing sessions or use the auditconfig command to update the users' preselection masks.

    • Terminate the users' existing sessions.

      Users can log out and log back in, or the administrator can manually terminate (kill) active sessions. The new sessions will inherit the new preselection mask. However, terminating users could be impractical.

    • Dynamically change each user's preselection mask.

      Assume that the flags attribute in the audit_control file was changed from lo to lo,ex.

      1. Determine the user's audit ID and audit session ID.

        First, find all regular users. In the following example, the administrator finds all processes that are not owned by root, daemon, or lp:


        # /usr/bin/pgrep -v -u root,daemon,lp | more 
        ..
        3941
        3948
        3949
        10640 ...

        Then, use one of the user's processes to find the user's audit ID:


        # auditconfig -getpinfo 3941
        audit id = jdoe(1002)
        process preselection mask = lo(0x1000,0x1000)
        terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
        audit session id = 713

        Note that the user's preselection mask includes the lo class and does not include the newly added ex class.

      The user's audit ID is 1002. The user's audit session ID is 713.

  2. Change the user's preselection mask

    Use one of the following two methods:

    • Use the user's audit session ID to change the user's preselection mask.


      # /usr/sbin/auditconfig -setsmask lo,ex 713
      
    • Use the user's audit ID to change the user's preselection mask.


      # /usr/sbin/auditconfig -setumask lo,ex 1002
      
  3. Verify that the preselection mask has changed.


    # auditconfig -getpinfo 3941
    audit id = jdoe(1002)
    process preselection mask = ex,lo(0x40001000,0x40001000) 
    terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
    audit session id = 713

ProcedureHow to Prevent the Auditing of Certain Events

For maintenance purposes, sometimes a site wants to prevent audit events from being audited.

  1. Change the class of the event to the no class.

    For example, events 26 and 27 belong to the pm class.


    ## audit_event file
    ...
    25:AUE_VFORK:vfork(2):ps
    26:AUE_SETGROUPS:setgroups(2):pm
    27:AUE_SETPGRP:setpgrp(2):pm
    28:AUE_SWAPON:swapon(2):no
    ...

    Change these events to the no class.


    ## audit_event file
    ...
    25:AUE_VFORK:vfork(2):ps
    26:AUE_SETGROUPS:setgroups(2):no
    27:AUE_SETPGRP:setpgrp(2):no
    28:AUE_SWAPON:swapon(2):no
    ...

    If the pm class is currently being audited, existing sessions will still audit events 26 and 27. To stop these events from being audited, you must update the users' preselection masks.


    Caution – Caution –

    Never comment out events in the audit_event file. This file is used by the praudit command to read binary audit files. Archived audit files might contain events that are listed in the file.


  2. To update the preselection masks of users, follow the instructions in How to Modify a User's Preselection Mask.

ProcedureHow to Limit the Size of Binary Audit Files

Binary audit files grow without limit. For ease of archiving and searching, you might want to limit the size. You can also create smaller binary files from the original file.

  1. Use the p_fsize attribute to limit the size of individual binary audit files.

    The p_fsize attribute to the audit_binfile.so plugin enables you to limit the size of an audit file. The default value is zero (0), which allows the file to grow without limit. The value is specified in bytes, from 512,000 to 2,147,483,647. When the specified size is reached, the current audit file is closed and a new file is opened.

    In the following example, you limit the size of and audit file to 1Mbyte:


    plugin:name=audit_binfile.so; p_dir:/var/audit; p_fsize=1024000
  2. Use the auditreduce command to select records and write those records to a file for further analysis.

    The auditreduce -lowercase options find specific records.

    The auditreduce -Uppercase options write your selections to a file. For more information, see the auditreduce(1M) man page.

ProcedureHow to Audit Logins From Other OSes

The Solaris OS can audit all logins, independent of source.

  1. Audit the lo class for attributable and for non-attributable events.

    This class audits logins, logouts, and screen locks.


    ## audit_control file
    flags:lo
    naflags:lo
    ...

    Note –

    To audit ssh logins, your Solaris system must be running the Solaris ssh daemon. This daemon is modified for Solaris auditing. For more information, see Solaris Secure Shell and the OpenSSH Project.


ProcedureHow to Audit FTP and SFTP File Transfers

The FTP service creates logs of its file transfers. The SFTP service, which runs under the SSH protocol, can be audited by Solaris auditing. Logins to both services can be audited by Solaris auditing.

  1. To log commands and file transfers of the FTP service, see the ftpaccess(4) man page.

    For the available logging options, read the “Logging Capabilities” section. In particular, the log commands and log transfers options might provide useful logs.

  2. To log sftp file transfers, perform one or both of the following:

    • Audit file-reads.

      File transfers over an SSH connection use the sftp command. These transfers can be recorded by using the +fr audit flag. To audit failed sftp file transfers, audit the -fr audit flag.

      The following output is from a successful sftp session:


      header,138,2,open(2) - read,,ma2,2009-08-25 14:48:58.770 -07:00
      path,/home/jdoe/vpn_connect
      attribute,100644,jdoe,staff,391,437,0
      subject,jdoe,jdoe,staff,jdoe,staff,4444,120289379,8457 65558 ma1
      return,success,6
    • Use the verbose option to the sftp command.

      The -v option can be repeated up to three times.


      # sftp -vvv [ other options ] hostname 
      
  3. To record access to the FTP and SFTP services, audit the lo class.

    As the following output indicates, logging in to and out of the ftpd daemon generates audit records.


    % bsmrecord -c lo | more
    ...
    in.ftpd
      program     /usr/sbin/in.ftpd    See ftp access
      event ID    6165                 AUE_ftpd
      class       lo                   (0x00001000)
          header
          subject
          [text]                       error message
          return
    
    in.ftpd
      program     /usr/sbin/in.ftpd    See ftp logout
      event ID    6171                 AUE_ftpd_logout
      class       lo                   (0x00001000)
          header
          subject
          return
    ...

    The SSH login records all accesses to the sftp command.


    ...
    /usr/lib/ssh/sshd
      program     /usr/lib/ssh/sshd    See login - ssh
      event ID    6172                 AUE_ssh
      class       lo                   (0x00001000)
          header
          subject
          [text]                       error message
          return

Chapter 31 Solaris Auditing (Reference)

This chapter describes the important components of Solaris auditing. The following is a list of the reference information in this chapter.

For an overview of Solaris auditing, see Chapter 28, Solaris Auditing (Overview). For planning suggestions, see Chapter 29, Planning for Solaris Auditing. For procedures to configure auditing at your site, see Chapter 30, Managing Solaris Auditing (Tasks).

Solaris Audit Service

The Solaris audit service, auditd, is configured by using the following auditconfig subcommands:

The auditconfig -t subcommand command creates a temporary, or active, value. Without the -t option, the values are persistent, or configured. For more information, see the auditconfig(1M) man page.

The bsmconv command enables the audit service initially. The service is stopped and restarted by using the audit -t and audit -s commands, respectively. The bsmunconv command disables the service permanently.

For more information, see the audit(1M), auditconfig(1M), and bsmconv(1M) man pages.

Audit Commands

This section provides information about the following commands:

auditd Daemon

The following list summarizes the tasks of the auditd daemon:

The auditd daemon can be started automatically when the system is booted into multiuser mode. Or, you can start the daemon from the command line by running the audit -s command after auditing has been enabled with the bsmconv command. When the auditd daemon is started, it calculates the amount of free space that is necessary for audit files.

The auditd daemon uses the list of audit directories in the audit_control file as possible locations for creating audit files. The daemon maintains a pointer into this list of directories, starting with the first directory. Every time the auditd daemon needs to create an audit file, the daemon puts the file into the first available directory in the list. The list starts at the auditd daemon's current pointer. You can reset the pointer to the beginning of the list by running the audit -s command. The audit -n command instructs the daemon to switch to a new audit file. The new file is created in the same directory as the current file.

audit Command

The audit command controls the actions of the auditd daemon. The audit command can do the following tasks:

For a discussion of the available options, see the audit(1M) man page.

auditrecord Command

The auditrecord command displays the format of audit events that are defined in the /etc/security/audit_event file. The output includes the event's audit ID, audit class, audit flag, and the record's audit tokens in order. With no option, the auditrecord output displays in a terminal window. With the -h option, the output is suitable for viewing in a browser. For examples of the use of the auditrecord command, see How to Display Audit Record Formats. Also, see the auditrecord(1M) man page.

auditreduce Command

The auditreduce command summarizes audit records that are stored in binary format. The command can merge audit records from one or more input audit files. The command can also be used to perform a post selection of audit records. The records remain in binary format. To merge the entire audit trail, run this command on the audit server. The audit server is the system that mounts all the audit file systems for the installation. For more information, see the auditreduce(1M) man page.

The auditreduce command enables you to track all audited actions on multiple systems from a single location. The command can read the logical combination of all audit files as a single audit trail. You must identically configure all systems at a site for auditing, and create servers and local directories for the audit files. The auditreduce command ignores how the records were generated or where the records are stored. Without options, the auditreduce command merges audit records from all the audit files in all of the subdirectories in the audit root directory. Typically, /etc/security/audit is the audit root directory. The auditreduce command sends the merged results to standard output. You can also place the results into a single, chronologically ordered output file. The file contains binary data.

The auditreduce command can also select particular types of records for analysis. The merging functions and selecting functions of the auditreduce command are logically independent. The auditreduce command captures data from the input files as the records are read, before the files are merged and then written to disk.

By specifying options to the auditreduce command, you can also do the following:

With no arguments, the auditreduce command checks the subdirectories within the /etc/security/audit directory, the default audit root directory. The command checks for a files directory in which the start-time.end-time.hostname files reside. The auditreduce command is very useful when audit data resides in separate directories. Figure 31–1 illustrates audit data in separate directories for different hosts. Figure 31–2 illustrates audit data in separate directories for different audit servers.

Figure 31–1 Audit Trail Storage Sorted by Host

Diagram shows a default audit root directory whose top
directory names are host names.

Figure 31–2 Audit Trail Storage Sorted by Server

Diagram shows a default audit root directory whose top
directory names are server names.

If the partition for the /etc/security/audit directory is very small, you might not store audit data in the default directory. You can pass the auditreduce command another directory by using the -R option:


# auditreduce -R /var/audit-alt 

You can also specify a particular subdirectory by using the -S option:


# auditreduce -S /var/audit-alt/host1 

For other options and more examples, see the auditreduce(1M) man page.

praudit Command

The praudit command makes the binary output of the auditreduce command readable. The praudit command reads audit records in binary format from standard input and displays the records in a presentable format. The input can be piped from the auditreduce command or from a single audit file. Input can also be produced with the cat command to concatenate several files, or the tail command for a current audit file.

The praudit command can generate four output formats. A fifth option, -l (long), prints one audit record per line of output. The default is to place one audit token per line of output. The -d option changes the delimiter that is used between token fields and between tokens. The default delimiter is a comma.

In the default output format of the praudit command, each record is easily identified as a sequence of audit tokens. Each token is presented on a separate line. Each record begins with a header token. You could, for example, further process the output with the awk command.

Here is the output from the praudit -l command for a header token:


header,173,2,settppriv(2),,example1,2003-10-13 13:46:02.174 -07:00

Here is the output from the praudit -r command for the same header token:


121,173,2,289,0x0000,192.168.86.166,1066077962,174352445

Example 31–1 Processing praudit Output With a Script

You might want to process output from the praudit command as lines of text. For example, you might want to select records that the auditreduce command cannot select. You can use a simple shell script to process the output of the praudit command. The following simple example script puts one audit record on one line, searches for a user-specified string, then returns the audit file to its original form.


#!/bin/sh
#
## This script takes an argument of a user-specified string.
#  The sed command prefixes the header tokens with Control-A
#  The first tr command puts the audit tokens for one record 
#  onto one line while preserving the line breaks as Control-A
#
praudit | sed -e '1,2d' -e '$s/^file.*$//' -e 's/^header/^aheader/' \\
| tr '\\012\\001' '\\002\\012' \\
| grep "$1" \\ Finds the user-specified string
| tr '\\002' '\\012' Restores the original newline breaks

Note that the ^a in the script is Control-A, not the two characters ^ and a. The prefix distinguishes the header token from the string header that might appear as text.


auditconfig Command

The auditconfig command provides a command-line interface to retrieve and set audit configuration parameters. The auditconfig command can do the following tasks:

For a discussion of the command options, see the auditconfig(1M) man page.

Files Used in the Audit Service

The audit service uses the following files:

system File

The /etc/system file contains commands that the kernel reads during initialization to customize the system operations. The bsmconv and bsmunconv shell scripts, which are used to activate and deactivate auditing, modify the /etc/system file. The bsmconv shell script adds the following line to the /etc/system file:


set c2audit:audit_load=1

The set c2audit:audit_load=1 entry causes the kernel module for auditing to be loaded when the system is booted. The bsmunconv shell script disables auditing when the system is rebooted. The command removes the c2audit line from the /etc/system file.

syslog.conf File

The /etc/syslog.conf file works with the audit_control file to store audit records in text format. The syslog.conf file can be configured to enable the syslog utility to store audit records. For an example, see How to Configure syslog Audit Logs.

audit_class File

The /etc/security/audit_class file defines the audit classes. Audit classes are groups of audit events. You use the class name in the audit_control file to preselect the classes whose events you want to audit. The classes accept prefixes to select only failed events or only successful events. For more information, see Audit Class Syntax.

The superuser, or an administrator in an equivalent role, can modify the definitions of audit classes. This administrator can define new audit classes, rename existing classes, or otherwise change existing classes by editing the audit_class file in a text editor. For more information, see the audit_class(4) man page.

audit_control File

The /etc/security/audit_control file on each system contains configuration information for the auditd daemon. The file enables every system to mount a remote audit file system to store their audit records.

You can specify five kinds of information in the audit_control file. Each line of information begins with a keyword.

For more information about the audit_control file, see the audit_control(4) man page. For information about the plugins, see Audit Plugins and the audit_binfile(5) and audit_syslog(5) man pages.


Example 31–2 Sample audit_control File

The following is a sample audit_control file for the system noddy. noddy uses two audit file systems on the audit server blinken, and a third audit file system that is mounted from the second audit server winken. The third file system is used only when the audit file systems on blinken become full or unavailable. The p_minfree value of 20 percent specifies that the warning script is run when the file systems are 80 percent full. The settings specify that logins and administrative operations are to be audited. The operations are audited for success and for failure. Failures of all types, except failures to create a file system object, are to be audited. Nonattributable events are also audited. The syslog audit log records fewer audit events. This log contains text summaries of failed logins and failed administrative operations.

In the following example, the plugin lines do not contain a line break.


flags:lo,am,-all,^-fc
naflags:lo,nt
plugin:name=audit_binfile.so; p_minfree=20; p_dir=/var/audit/blinken/files,
/var/audit/blinken.1/files,/var/audit/winken
plugin:name=audit_syslog.so; p_flags=-lo,-am

audit_event File

The /etc/security/audit_event file contains the default audit event-class mappings. You can edit this file to change the class mappings. When you change class mappings, you must reboot the system or run the auditconfig -conf command to read the changed mappings into the kernel. For more information, see the audit_event(4) man page.

audit_user Database

The /etc/security/audit_user database modifies the system-wide preselected classes for an individual user. The classes that you add to a user's entry in the audit_user database modify the settings in the audit_control file in two ways:

Each user entry in the audit_user database contains three fields:


username:always-audit-classes:never-audit-classes

The audit fields are processed in sequence.

Suppose that you want to apply the system-wide audit settings to the user tamiko, except for successful reads of file system objects. Note the placement of the second colon (:) in the following audit_user entry:


tamiko:^+fr:no  modify system defaults for fr

The preceding entry means, “always audit everything, except for successful file reads.”

If you want to audit everything for user tamiko with the exception of successful file reads, you use the following entry:


tamiko:all,^+fr:no  audit everything except fr

Suppose that you want to override system defaults for successful file-reads for user tamiko. The following entry means “always audit everything, but never audit successful file reads.”


tamiko:all:+fr    override system defaults for fr

Note –

Successful events and failed events are treated separately. A process could generate more audit records for failed events than for successful events.


audit_warn Script

The /etc/security/audit_warn script notifies an email alias when the auditd daemon encounters an unusual condition while writing audit records. You can customize this script for your site to warn of conditions that might require manual intervention. Or, you could specify how to handle those conditions automatically. For all error conditions, the audit_warn script writes a message to syslog with the severity of daemon.alert. You can use syslog.conf to configure console display of syslog messages. The audit_warn script also sends a message to the audit_warn email alias. You set up this alias as part of audit configuration.

When the auditd daemon detects the following conditions, the daemon invokes the audit_warn script. The script sends email to the audit_warn alias.

If the perzone audit policy is set, the non-global zone's instance of auditd calls the zone's audit_warn script. For further information, see the audit_warn(1M) man page.

bsmconv Script

The /etc/security/bsmconv script enables the audit service. The bsmunconv command disables the audit service. After the bsmconv script is run, you configure the audit directories and audit configuration files. Upon reboot, auditing is enabled.

For further information, see the bsmconv(1M) man page.

Rights Profiles for Administering Auditing

The Solaris OS provides rights profiles for configuring the audit service and for analyzing the audit trail.

To configure roles to handle the audit service, see Configuring RBAC (Task Map).

Auditing and Solaris Zones

Non-global zones can be audited exactly as the global zone is audited, or nonglobal zones can set their own flags, storage, and audit policy.

When all zones are being audited identically, the configuration files in the global zone provide the settings for auditing in every zone. The +zonename policy option is useful. When this option is set, the audit records from all zones include the name of the zone. Audit records can then be postselected by zone name. To understand audit policy, see Determining Audit Policy. For an example, see How to Configure Audit Policy.

Zones can also be audited individually. When the policy option, perzone, is set in the global zone, each non-global zone runs its own audit daemon, handles its own audit queue, and specifies the content and location of its audit records. A non-global zone can also set most audit policy options. It cannot set policy that affects the entire system, so a non-global zone cannot set the ahlt or perzone policy. For further discussion, see Auditing on a System With Zones and How to Plan Auditing in Zones.

To learn about zones, see Part II, Zones, in System Administration Guide: Virtualization Using the Solaris Operating System.

Audit Classes

System-wide defaults for Solaris auditing are preselected by specifying one or more classes of events. The classes are preselected for each system in the system's audit_control file. Anyone who uses the system is audited for these classes of events. The file is described in audit_control File.

You can configure audit classes and make new audit classes. Audit class names can be up to 8 characters in length. The class description is limited to 72 characters. Numeric and non-alphanumeric characters are allowed.

You can modify what is audited for individual users by adding audit classes to a user's entry in the audit_user database. The audit classes are also used as arguments to the auditconfig command. For details, see the auditconfig(1M) man page.

Definitions of Audit Classes

The following table shows each predefined audit class, the descriptive name for each audit class, and a short description.

Table 31–1 Predefined Audit Classes

Audit Class 

Descriptive Name 

Description 

all

all

All classes (metaclass) 

no

no_class

Null value for turning off event preselection

na

non_attrib

Nonattributable events 

fr

file_read

Read of data, open for reading 

fw

file_write

Write of data, open for writing 

fa

file_attr_acc

Access of object attributes: stat, pathconf

fm

file_attr_mod

Change of object attributes: chown, flock

fc

file_creation

Creation of object 

fd

file_deletion

Deletion of object 

cl

file_close

close system call

ap

application

Application-defined event 

ad

administrative

Administrative actions (old administrative metaclass) 

am

administrative

Administrative actions (metaclass) 

ss

system state

Change system state 

as

system-wide administration

System-wide administration 

ua

user administration

User administration 

aa

audit administration

Audit utilization 

ps

process start

Process start and process stop 

pm

process modify

Process modify 

pc

process

Process (metaclass) 

ex

exec

Program execution 

io

ioctl

ioctl() system call

ip

ipc

System V IPC operations

lo

login_logout

Login and logout events 

nt

network

Network events: bind, connect, accept

ot

other

Miscellaneous, such as device allocation and memcntl()

You can define new classes by modifying the /etc/security/audit_class file. You can also rename existing classes. For more information, see the audit_class(4) man page.

Audit Class Syntax

Events can be audited for success, events can be audited for failure, and events can be audited for both. Without a prefix, a class of events is audited for success and for failure. With a plus (+) prefix, a class of events is audited for success only. With a minus (-) prefix, a class of events is audited for failure only. The following table shows some possible representations of audit classes.

Table 31–2 Plus and Minus Prefixes to Audit Classes

[prefix]class

Explanation 

lo

Audit all successful attempts to log in and log out, and all failed attempts to log in. A user cannot fail an attempt to log out. 

+lo

Audit all successful attempts to log in and log out. 

-all

Audit all failed events. 

+all

Audit all successful events. 


Caution – Caution –

The all class can generate large amounts of data and quickly fill audit file systems. Use the all class only if you have extraordinary reasons to audit all activities.


Audit classes that were previously selected can be further modified by a caret prefix, ^. The following table shows how the caret prefix modifies a preselected audit class.

Table 31–3 Caret Prefix That Modifies Already-Specified Audit Classes

^[prefix]class

Explanation 

-all,^-fc

Audit all failed events, except do not audit failed attempts to create file objects 

am,^+aa

Audit all administrative events for success and for failure, except do not audit successful attempts to administer auditing

am,^ua

Audit all administrative events for success and for failure, except do not audit user administration events 

The audit classes and their prefixes can be used in the following files and commands:

See audit_control File for an example of using the prefixes in the audit_control file.

Audit Plugins

Audit plugins specify how to handle the audit records in the audit queue. The audit plugins are specified by name in the audit_control file: audit_binfile.so, audit_remote.so, and audit_syslog.so.The plugins and their parameters can specify the following:

Refer to the audit_binfile(5), audit_remote(5), audit_syslog(5), and audit_control(4) man pages.

Audit Policy

Audit policy determines if additional information is added to the audit trail.

The following policies add tokens to audit records: arge, argv, group, path, seq, trail, windata_down, windata_up, and zonename.

The remaining policies do not add tokens. The ahlt and cnt policies determine what happens when kernel audit records cannot be delivered, the public policy limits auditing of public files, and the perzone policy establishes separate audit queues for non-global zones.

The effects of the different audit policy options are described in Determining Audit Policy. For a description of audit policy options, see the -setpolicy option in the auditconfig(1M) man page. For a list of available policy options, run the auditconfig -lspolicy command.

Process Audit Characteristics

The following audit characteristics are set at initial login:

Audit Trail

The audit trail is contains binary audit files. The trail is created by the auditd daemon. Once the audit service has been enabled with the bsmconv command, the auditd daemon starts when the system is booted. The auditd daemon is responsible for collecting the audit trail data and writing the audit records.

The audit records are stored in binary format on file systems that are dedicated to audit files. Even though you can physically locate audit directories within file systems that are not dedicated to auditing, do not do so except for directories of last resort. Directories of last resort are directories where audit files are written only when no other suitable directory is available.

There is one other scenario where locating audit directories outside of dedicated audit file systems could be acceptable. You might do so in a software development environment where auditing is optional. To make full use of disk space might be more important than to keep an audit trail. However, in a security-conscious environment, the placement of audit directories within other file systems is not acceptable.

You should also consider the following factors when administering audit file systems:

Conventions for Binary Audit File Names

Each binary audit file is a self-contained collection of records. The file's name identifies the time span during which the records were generated and the system that generated them.

Binary Audit File Names

Audit files that are complete have names of the following form:


start-time.end-time.system
start-time

Is the time that the first audit record in the audit file was generated

end-time

Is the time that the last record was written to the file

system

Is the name of the system that generated the file

An audit file that is still active has a name of the following form:


start-time.not_terminated.system

For examples of not_terminated and closed audit file names, see How to Clean Up a not_terminated Audit File.

Binary Audit File Timestamps

The timestamps in file names are used by the auditreduce command to locate records within a specific time range. These timestamps are important because there can be a month's accumulation or more of audit files online. To search all the files for records that were generated in the last 24 hours would be unacceptably expensive.

The start-time and end-time are timestamps with one-second resolution. They are specified in Greenwich Mean Time (GMT). The format is four digits for the year, followed by two digits for each month, day, hour, minute, and second, as follows:


YYYYMMDDHHMMSS

The timestamps are in GMT to ensure that they sort in proper order, even across time zones. Because they are in GMT, the date and hour must be translated to the current time zone to be meaningful. Beware of this point whenever you manipulate these files with standard file commands rather than with the auditreduce command.

Audit Record Structure

An audit record is a sequence of audit tokens. Each audit token contains event information such as user ID, time, and date. A header token begins an audit record, and an optional trailer token concludes the record. Other audit tokens contain information relevant to the audit event. The following figure shows a typical audit record.

Figure 31–3 Typical Audit Record Structure

Diagram shows a typical audit record structure, which
includes a header token followed by an arg, a data, a subject, and a return
token.

Audit Record Analysis

Audit record analysis involves postselecting records from the audit trail. You can use one of two approaches to parsing the binary data that was collected.

Audit Token Formats

Each audit token has a token type identifier, which is followed by data that is specific to the token. Each token type has its own format. The following table shows the token names with a brief description of each token. Obsolete tokens are maintained for compatibility with previous Solaris releases.

Table 31–4 Audit Tokens for Solaris Auditing

Token Name 

Description 

For More Information 

acl

Access Control List (ACL) information 

acl Token

arbitrary

Data with format and type information 

See the audit.log(4) man page.

arg

System call argument value 

arg Token

attribute

File vnode tokens 

attribute Token

cmd

Command arguments and environment variables

cmd Token

exec_args

Exec system call arguments 

exec_args Token

exec_env

Exec system call environment variables 

exec_env Token

exit

Program exit information 

See the audit.log(4) man page.

file

Audit file information 

file Token

fmri

Framework Management Resource Indicator token 

fmri Token

group

Process groups information 

See groups Token.

groups

Process groups information 

groups Token

header

Indicates start of audit record 

header Token

in_addr

Internet address 

in_addr Token

ip

IP header information 

See the audit.log(4) man page.

ipc

System V IPC information 

ipc Token

ipc_perm

System V IPC object tokens 

ipc_perm Token

iport

Internet port address 

iport Token

opaque

Unstructured data (unspecified format) 

See the audit.log(4) man page.

path

Path information 

path Token

path_attr

Access path information 

path_attr Token

privilege

Privilege set information 

privilege Token

process

Process token information 

process Token

return

Status of system call 

return Token

sequence

Sequence number token 

sequence Token

socket

Socket type and addresses 

socket Token

subject

Subject token (same format as process token)

subject Token

text

ASCII string 

text Token

trailer

Indicates end of audit record 

trailer Token

uauth

Use of authorization 

uauth Token

upriv

Use of privilege 

upriv Token

zonename

Name of zone 

zonename Token

An audit record always begins with a header token. The header token indicates where the audit record begins in the audit trail. In the case of attributable events, the subject and the process tokens refer to the values of the process that caused the event. In the case of nonattributable events, the process token refers to the system.

acl Token

The acl token records information about Access Control Lists (ACLs).

The praudit -x command shows the fields of the acl token:


<acl type="1" value="root" mode="6"/>

arg Token

The arg token contains information about the arguments to a system call: the argument number of the system call, the argument value, and an optional description. This token allows a 32-bit integer system-call argument in an audit record.

The praudit -x command shows the fields of the arg token:


<argument arg-num="2" value="0x0" desc="new file uid"/>

attribute Token

The attribute token contains information from the file vnode.

The attribute token usually accompanies a path token. The attribute token is produced during path searches. If a path-search error occurs, there is no vnode available to obtain the necessary file information. Therefore, the attribute token is not included as part of the audit record. The praudit -x command shows the fields of the attribute token:


<attribute mode="100644" uid="adm" gid="adm" fsid="136" nodeid="2040" device="0"/>

cmd Token

The cmd token records the list of arguments and the list of environment variables that are associated with a command.

The praudit -x command shows the fields of the cmd token. The following is a truncated cmd token. The line is wrapped for display purposes.


<cmd><arge>WINDOWID=6823679</arge>
<arge>COLORTERM=gnome-terminal</arge>
<arge>...LANG=C</arge>...<arge>HOST=machine1</arge>
<arge>LPDEST=printer1</arge>...</cmd>

exec_args Token

The exec_args token records the arguments to an exec() system call. The exec_args token has two fixed fields:

The remainder of this token is composed of count strings. The praudit -x command shows the fields of the exec_args token:


<exec_args><arg>/usr/bin/sh</arg><arg>/usr/bin/hostname</arg></exec_args>

Note –

The exec_args token is output only when the argv audit policy option is active.


exec_env Token

The exec_env token records the current environment variables to an exec() system call. The exec_env token has two fixed fields:

The remainder of this token is composed of count strings. The praudit -x command shows the fields of the exec_env token. The line is wrapped for display purposes.


<exec_env><env>_=/usr/bin/hostname</env>
<env>DTXSERVERLOCATION=local</env><env>SESSIONTYPE=altDt</env>
<env>LANG=C</env><env>SDT_NO_TOOLTALK=1</env><env>SDT_ALT_HELLO=/bin/true</env>
<env>PATH=/usr/bin:/usr/openwin/bin:/usr/ucb</env>
<env>OPENWINHOME=/usr/openwin</env><env>LOGNAME=jdoe</env><env>USER=jdoe</env>
<env>DISPLAY=:0</env><env>SHELL=/bin/csh</env><env>START_SPECKEYSD=no</env>
<env>SDT_ALT_SESSION=/usr/dt/config/Xsession2.jds</env><env>HOME=/home/jdoe</env>
<env>SDT_NO_DTDBCACHE=1</env><env>PWD=/home/jdoe</env><env>TZ=US/Pacific</env>
</exec_env>

Note –

The exec_env token is output only when the arge audit policy option is active.


file Token

The file token is a special token that is generated by the auditd daemon. The token marks the beginning of a new audit file and the end of an old audit file as the old file is deactivated. The initial file token identifies the previous file in the audit trail. The final file token identifies the next file in the audit trail. The auditd daemon builds a special audit record that contains this token to “link” together successive audit files into one audit trail.

The file token has four fields:

The praudit -x command shows the fields of the file token. This token identifies the next file in the audit trail. The line is wrapped for display purposes.


<file iso8601="2009-04-08 14:18:26.200 -07:00">
/var/audit/machine1/files/20090408211826.not_terminated.machine1</file>

fmri Token

The fmri token records the use of a fault management resource indicator (FMRI). For more information, see the smf(5) man page.

The praudit -x command shows the content of the fmri token:


<fmri service_instance="svc:/system/cryptosvc"</fmri>

groups Token

The groups token replaces the group token. The groups token records the group entries from the process's credential.

The praudit -x command shows the fields of the groups token:


<group><gid>staff</gid><gid>other</gid></group>

Note –

The groups token is output only when the group audit policy option is active.


header Token

The header token is special in that it marks the beginning of an audit record. The header token combines with the trailer token to bracket all the other tokens in the record.

On 64-bit systems, the header token is displayed with a 64-bit timestamp, in place of the 32-bit timestamp.

The praudit command displays the header token as follows:


header,69,2,su,,machine1,2009-04-08 13:11:58.209 -07:00

The praudit -x command displays the fields of the header token at the beginning of the audit record. The line is wrapped for display purposes.


<record version="2" event="su" host="machine1" 
iso8601="2009-04-08 13:11:58.209 -07:00">

in_addr Token

The in_addr token contains an Internet Protocol address. Since the Solaris 8 release, the Internet address can be displayed in IPv4 format or IPv6 format. The IPv4 address uses 4 bytes. The IPv6 address uses 1 byte to describe the address type, and 16 bytes to describe the address.

The praudit -x command shows the content of the in_addr token:


<ip_address>machine1</ip_address>

ipc Token

The ipc token contains the System V IPC message handle, semaphore handle, or shared-memory handle that is used by the caller to identify a particular IPC object.


Note –

The IPC object identifiers violate the context-free nature of the Solaris audit tokens. No global “name” uniquely identifies IPC objects. Instead, IPC objects are identified by their handles. The handles are valid only during the time that the IPC objects are active. However, the identification of IPC objects should not be a problem. The System V IPC mechanisms are seldom used, and the mechanisms all share the same audit class.


The following table shows the possible values for the IPC object type field. The values are defined in the /usr/include/bsm/audit.h file.

Table 31–5 Values for the IPC Object Type Field

Name 

Value 

Description 

AU_IPC_MSG

IPC message object 

AU_IPC_SEM

IPC semaphore object 

AU_IPC_SHM

IPC shared-memory object 

The praudit -x command shows the fields of the ipc token:


<IPC ipc-type="shm" ipc-id="15"/>

ipc_perm Token

The ipc_perm token contains a copy of the System V IPC access permissions. This token is added to audit records that are generated by IPC shared-memory events, IPC semaphore events, and IPC message events.

The praudit -x command shows the fields of the ipc_perm token. The line is wrapped for display purposes.


<IPC_perm uid="jdoe" gid="staff" creator-uid="jdoe" 
creator-gid="staff" mode="100600" seq="0" key="0x0"/>

The values are taken from the ipc_perm structure that is associated with the IPC object.

iport Token

The iport token contains the TCP or UDP port address.

The praudit command displays the iport token as follows:


ip port,0xf6d6

path Token

The path token contains access path information for an object.

The praudit -x command shows the content of the path token:


<path>/etc/security/audit_user</path>

path_attr Token

The path_attr token contains access path information for an object. The access path specifies the sequence of attribute file objects below the path token object. Systems calls such as openat() access attribute files. For more information on attribute file objects, see the fsattr(5) man page.

The praudit command displays the path_attr token as follows:


path_attr,1,attr_file_name

privilege Token

The privilege token records the use of privileges on a process. The privilege token is not recorded for privileges in the basic set. If a privilege has been removed from the basic set by administrative action, then the use of that privilege is recorded. For more information on privileges, see Privileges (Overview)

The praudit -x command shows the fields of the privilege token. The line is wrapped for display purposes.


<privilege set-type="Effective">file_chown,file_dac_read,
file_dac_write,net_privaddr,proc_exec,proc_fork,proc_setid</privilege>

process Token

The process token contains information about a user who is associated with a process, such as the recipient of a signal.

The praudit -x command shows the fields of the process token. The line is wrapped for display purposes.


<process audit-uid="-2" uid="root" gid="root" ruid="root" 
rgid="root" pid="9" sid="0" tid="0 0 0.0.0.0"/>

return Token

The return token contains the return status of the system call (u_error) and the process return value (u_rval1).

The return token is always returned as part of kernel-generated audit records for system calls. In application auditing, this token indicates exit status and other return values.

The praudit command displays the return token for a system call as follows:


return,failure: Operation now in progress,-1

The praudit -x command shows the fields of the return token:


<return errval="failure: Operation now in progress" retval="-1/">

sequence Token

The sequence token contains a sequence number. The sequence number is incremented every time an audit record is added to the audit trail. This token is useful for debugging.

The praudit -x command shows the content of the sequence token:


<sequence seq-num="1292"/>

Note –

The sequence token is output only when the seq audit policy option is active.


socket Token

The socket token contains information that describes an Internet socket. In some instances, the token has four fields:

The praudit command displays this instance of the socket token as follows:


socket,0x0002,0x83b1,localhost

In most instances, the token has eight fields:

Since the Solaris 8 release, the Internet address can be displayed in IPv4 format or IPv6 format. The IPv4 address uses 4 bytes. The IPv6 address uses 1 byte to describe the address type, and 16 bytes to describe the address.

The praudit -x command shows the fields of the socket token. The line is wrapped for display purposes.


<socket sock_domain="0x0002" sock_type="0x0002" lport="0x83cf" 
laddr="example1" fport="0x2383" faddr="server1.Subdomain.Domain.COM"/>

subject Token

The subject token describes a user who performs or attempts to perform an operation. The format is the same as the process token.

The subject token is always returned as part of kernel-generated audit records for system calls. The praudit command displays the subject token as follows:


subject,jdoe,root,root,root,root,1631,1421584480,8243 65558 machine1

The praudit -x command shows the fields of the subject token. The line is wrapped for display purposes.


<subject audit-uid="jdoe" uid="root" gid="root" ruid="root" 
rgid="root" pid="1631" sid="1421584480" tid="8243 65558 machine1"/>

text Token

The text token contains a text string.

The praudit -x command shows the content of the text token:


<text>booting kernel</text>

trailer Token

The two tokens, header and trailer, are special in that they distinguish the end points of an audit record and bracket all the other tokens. A header token begins an audit record. A trailer token ends an audit record. The trailer token is an optional token. The trailer token is added as the last token of each record only when the trail audit policy option has been set.

When an audit record is generated with trailers turned on, the auditreduce command can verify that the trailer correctly points back to the record header. The trailer token supports backward seeks of the audit trail.

The praudit command displays the trailer token as follows:


trailer,136

uauth Token

The uauth token records the use of authorization with a command or action.

The praudit command displays the uauth token as follows:


use of authorization,solaris.admin.printer.delete

upriv Token

The upriv token records the use of privilege with a command or action.

The praudit -x command shows the fields of the upriv token:


<use_of_privilege result="successful use of priv">proc_setid</use_of_privilege>

zonename Token

The zonename token records the zone in which the audit event occurred. The string “global” indicates audit events that occur in the global zone.

The praudit -x command shows the content of the zonename token:


<zone name="graphzone"/>