This section provides information on the configuration, management, and use of the Solaris auditing subsystem.
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).
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:
Monitoring security-relevant events that take place on the host
Recording the events in a network-wide audit trail
Detecting misuse or unauthorized activity
Reviewing patterns of access and the access histories of individuals and objects
Discovering attempts to bypass the protection mechanisms
Discovering extended use of privilege that occurs when a user changes identity
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.
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.
Auditing generates audit records when specified events occur. Most commonly, events that generate audit records include the following:
System startup and system shutdown
Login and logout
Process creation or process destruction, or thread creation or thread destruction
Opening, closing, creating, destroying, or renaming of objects
Use of privilege capabilities or role-based access control (RBAC)
Identification actions and authentication actions
Permission changes by a process or user
Administrative actions, such as installing a package
Site-specific applications
Audit records are generated from three sources:
By an application
As a result of an asynchronous audit event
As a result of a process system call
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 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.
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:
How system security was compromised
What loopholes need to be closed to ensure the desired level of security
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. |
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:
Attributable events – Events that can be attributed to a user. The exec() system call can be attributed to a user, so the call is considered an attributable event. All attributable events are synchronous events.
Nonattributable events – Events that occur at the kernel-interrupt level or before a user is authenticated. The na audit class handles audit events that are nonattributable. For example, booting the system is a nonattributable event. Most nonattributable events are asynchronous events. However, nonattributable events that have associated processes, such as failed login, are synchronous events.
Synchronous events – Events that are associated with a process in the system. Synchronous events are the majority of system events.
Asynchronous events – Events that are not associated with any process, so no process is available to be blocked and later woken up. Initial system boot and PROM enter and exit events are examples of asynchronous events.
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.
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.
System-wide preselection – Specify system-wide defaults for auditing in the flags, naflags, and plugin lines in the audit_control file. The audit_control file is described in audit_control File. See also the audit_control(4) man page.
User-specific preselection – Specify additions to the system-wide auditing defaults for individual users in the audit_user database.
The audit preselection mask determines which classes of events are audited for a user. The user's audit preselection mask is a combination of the system-wide defaults and the audit classes that are specified for the user. For a more detailed discussion, see Process Audit Characteristics.
The audit_user database can be administered locally or by a naming service. The Solaris Management Console provides the graphical user interface (GUI) to administer the database. For details, see the audit_user(4) man page.
Dynamic preselection – Specify audit classes as arguments to the auditconfig command to add or remove those audit classes from a process or session. For more information, see the auditconfig(1M) man page.
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.
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.
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.
audit_binfile.so plugin – Handles delivery of the audit queue to the binary audit files. In the audit_control file, if no plugin is specified and the dir entry has a value, then the audit daemon uses this plugin.
audit_syslog.so plugin – Handles delivery of selected records from the audit queue to the syslog logs.
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), and audit_control(4) man pages.
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:
audit_syslog(5) man page
audit.log(4) man page
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:
Primary audit directory – A directory where the audit files for a system are placed under normal conditions
Secondary audit directory – A directory where the audit files for a system are placed if the primary audit directory is full or not available
Directory of last resort – A local audit directory that is used if the primary audit directory and all secondary audit directories are not available
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.
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.
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:
The site requires a single-image audit trail.
The non-global zones are used as application containers. The zones are part of one administrative domain. That is, no non-global zone has customized naming service files.
If all the zones on a system are within one administrative domain, the zonename audit policy can be used to distinguish audit events that execute in different zones.
Administrators want low audit overhead. The global zone administrator audits all zones identically. Also, the global zone's audit daemon serves all zones on the system.
Sites that satisfy the following conditions can run one audit service per zone:
The site does not require a single-image audit trail.
The non-global zones have customized naming service files. These separate administrative domains typically function as servers.
Individual zone administrators want to control auditing in the zones that they administer. In per-zone auditing, zone administrators can decide to enable or to disable auditing for the zone that they administer.
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.
Since the Solaris 9 release, the following features have been introduced to Solaris auditing:
Solaris auditing can use the syslog utility to store audit records in text format. For discussion, see Audit Logs. To set up the audit_control file to use the syslog utility, see How to Configure syslog Audit Logs.
The praudit command has an additional output format, XML. XML is a standard, portable, processable format. The XML format enables the output to be read in a browser, and provides source for XML scripting for reports. The -x option to the praudit command is described in praudit Command.
The default set of audit classes has been restructured. Audit metaclasses provide an umbrella for finer-grained audit classes. For a list of the default set of classes, see Definitions of Audit Classes.
The bsmconv command no longer disables the use of the Stop-A key. The Stop-A event can be audited.
The timestamp in audit records is reported in ISO 8601 format. For information about the standard, see http://www.iso.org.
Three audit policy options have been added:
public – Public objects are no longer audited for read-only events. By not auditing public files, the audit log size is greatly reduced. Attempts to read sensitive files are therefore easier to monitor. For more on public objects, see Audit Terminology and Concepts.
perzone – The perzone policy has broad effects. A separate audit daemon runs in each zone. The daemon uses audit configuration files that are specific to the zone. Also, the audit queue is specific to the zone. For details, see the auditd(1M) and auditconfig(1M) man pages. For more on zones, see Auditing and Solaris Zones. For more on policy, see How to Plan Auditing in Zones.
zonename – The name of the Solaris zone in which an audit event occurred can be included in audit records. For more on zones, see Auditing and Solaris Zones. For a discussion of when to use the option, see Determining Audit Policy.
Five audit tokens have been added:
The cmd token records the list of arguments and the list of environment variables that are associated with a command. For more information, see cmd Token.
The path_attr token records the sequence of attribute file objects that are below the path token object. For more information, see path_attr Token.
The privilege token records the use of privilege on a process. For more information, see privilege Token.
The uauth token records the use of authorization with a command or action. For more information, see uauth Token.
The zonename token records the name of the non-global zone in which an audit event occurred. The zonename audit policy option determines whether the zonename token is included in the audit record. For more information, see zonename Token.
For overview information, see Auditing and Solaris Zones. To learn about zones, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
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).
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 | |
Plan storage space for the audit trail | |
Determine who and what to audit |
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.
If your system has implemented zones, you have two audit configuration possibilities:
You can configure a single audit service in the global zone for all zones.
You can configure one audit service per zone.
For a discussion of the trade-offs, see Auditing on a System With Zones.
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.
Copy the audit_control file from the global zone to every non-global zone.
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.
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.
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.
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.
If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.
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.
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.
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.
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.
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.
If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.
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_warn, audit_event, audit_class, and audit_startup files as every other system.
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.
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.
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.
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.
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.
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.
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.
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–16.
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.
Audit policy determines the characteristics of the audit records for the local system. The policy options are set by a startup script. The bsmconv script, which enables the auditing service, creates the /etc/security/audit_startup script. The audit_startup script executes the auditconfig command to establish audit policy. For details about the script, see the audit_startup(1M) man page.
Most audit policy options are disabled by default to minimize storage requirements and system processing demands. You can dynamically enable and disable audit policy options with the auditconfig command. You can permanently enable and disable the policy options with the audit_startup script.
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
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:
-ahlt +cnt is the default policy that is shipped. This default lets an audited event be processed even if the event cannot be logged.
The -ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, the system will count the events and continue processing. In the global zone, the as_dropped counter records the count.
The +cnt policy states that if a synchronous event arrives and the event cannot be placed in the kernel audit queue, the system will count the event and continue processing. The zone's as_dropped counter records the count.
The -ahlt +cnt configuration is generally used at sites where processing must continue, even if continued processing could result in a loss of audit records. The auditstatdrop field shows the number of audit records that are dropped in a zone.
The +ahlt -cnt policy states that processing halts when an event cannot be added to the kernel audit queue.
The +ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, all processing is stopped. The system will panic. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.
The -cnt policy states that if a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.
The +ahlt -cnt configuration is generally used in sites where a record of every audit event takes precedence over system availability. Programs will appear to hang until audit space becomes available. The auditstat wblk field shows the number of times that threads were blocked.
However, if an asynchronous event occurs, the system will panic, leading to an outage. The kernel queue of audit events can be manually recovered from a saved crash dump. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.
The -ahlt -cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the event will be counted and processing will continue. When a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.
The -ahlt -cnt configuration is generally used in sites where the recording of all synchronous audit events takes precedence over some potential loss of asynchronous audit records. The auditstat wblk field shows the number of times that threads were blocked.
The +ahlt +cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the system will panic. If a synchronous event cannot be placed in the kernel audit queue, the system will count the event and continue processing.
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
Cost of analysis of audit data
Cost of storage 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.
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.
Storage cost is the most significant cost of auditing. The amount of audit data depends on the following:
Number of users
Number of systems
Amount of use
Degree of traceability and accountability that is required
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:
Preselect audit classes judiciously to reduce the volume of records that are generated.
Full auditing, that is, with the all class, fills disks quickly. Even a simple task such as compiling a program could generate a large audit file. A program of modest size could generate thousands of audit records in less than a minute.
For example, by omitting the file_read audit class, fr, you can significantly reduce audit volume. By choosing to audit for failed operations only, you can at times reduce audit volume. For example, by auditing for failed file_read operations, -fr, you can generate far fewer records than by auditing for all file_read events.
Efficient audit file management is also important. After the audit records are created, file management reduces the amount of storage that is required.
Understand the audit classes
Before you configure auditing, you should understand the types of events that the classes contain. You can change the audit event-class mappings to optimize audit record collection.
Develop a philosophy of auditing for your site.
Base your philosophy on sensible measures. Such measures include the amount of traceability that your site requires, and the types of users that you administer.
The following techniques can help you achieve your organization's security goals while auditing more efficiently.
Randomly audit only a certain percentage of users at any one time.
Reduce the disk-storage requirements for audit files by combining, reducing, and compressing the files. Develop procedures for archiving the files, for transferring the files to removable media, and for storing the files offline.
Monitor the audit data in real time for unusual behaviors. You can extend management and analysis tools that you have already developed to handle audit records in syslog files.
You can also set up procedures to monitor the audit trail for certain activities. You can write a script to trigger an automatic increase in the auditing of certain users or certain systems in response to detection of unusual events.
For example, you could write a script that does the following:
Monitors the creation of audit files on all the audit file servers.
Processes the audit files with the tail command.
The piping of the output from the tail -0f command through the praudit command can yield a stream of audit records as the records are generated. For more information, see the tail(1) man page.
Analyzes this stream for unusual message types or other indicators, and delivers the analysis to the auditor.
Or, the script can be used to trigger automatic responses.
Constantly monitors the audit directories for the appearance of new not_terminated audit files.
Terminates outstanding tail processes when their files are no longer being written to.
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).
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. | |
2. Configure audit files |
Defines which events, classes, and users require auditing. | |
3. Configure and enable auditing |
Configures each host for disk space and other audit service requirements. Then, starts the audit service. | |
On a host that has installed non-global zones, configure one audit service for the system, or one audit service per zone. | ||
4. Manage audit records |
Collects and analyzes the audit data. |
The following task map points to the procedures for configuring files to customize auditing at your site. Most of the tasks are optional.
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).
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.
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.
(Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.orig |
Modify the audit_control file for your site.
Each entry has the following format:
keyword:value |
Defines the type of line. The types are dir, flags, minfree, naflags, and plugin. In the Solaris 10 release, the dir and minfree lines are deprecated.
For explanations of the keywords, see the following examples.
Specifies data that is associated with the line type.
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.
(Optional) Verify the syntax of the file.
# audit -v /etc/security/audit_control syntax ok |
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 bsmrecord command, as shown in Example 30–27.
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=... |
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.
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.
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.
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.
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.
(Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.save |
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 p_fsize attribute was introduced in Solaris 10 10/08.
For more information about the plugin-specific attributes, see the OBJECT ATTRIBUTES section of the audit_binfile(5) and audit_syslog(5) man pages.
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.
Create the log file.
# touch /var/adm/auditlog |
Refresh the configuration information for the syslog service.
# svcadm refresh system/system-log |
Regularly archive the syslog log files.
The audit service can generate extensive output. To manage the logs, see the logadm(1M) man page.
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.
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 |
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 |
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.
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.
(Optional) Save a backup copy of the audit_user database.
# cp /etc/security/audit_user /etc/security/audit_user.orig |
Add new entries to the audit_user database.
In the local database, each entry has the following format:
username:always-audit:never-audit |
Selects the name of the user to be audited.
Selects the list of audit classes that should always be audited for the specified user.
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.
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 |
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=... |
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.
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.
(Optional) Save a backup copy of the audit_class file.
# cp /etc/security/audit_class /etc/security/audit_class.orig |
Add new entries to the audit_class file.
Each entry has the following format:
0xnumber:name:description |
Identifies number as hexadecimal.
Defines the unique audit class mask.
Defines the letter name of the audit class.
Defines the descriptive name of the audit class.
The entry must be unique in the file. Do not use existing audit class masks.
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.
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.
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.
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.
(Optional) Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.orig |
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 |
Is the audit event ID.
Is the name of the audit event.
Typically, the system call or executable that triggers the creation of an audit record.
Is a comma-separated list of audit classes.
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 |
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 |
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. | |
2. Create audit partitions |
Creates disk space for the audit files, and protects them with file permissions. | |
3. Create the audit_warn alias |
Defines who should get email warnings when the audit service needs attention. | |
4. (Optional) Change audit policy |
Defines additional audit data that your site requires. | |
6. Configure auditing in non-global zones |
Enable non-global zones to collect auditing records | |
7. Enable auditing |
Turns on the audit service. | |
When perzone auditing is turned on, enables auditing in a non-global zone. | ||
8. (Optional) Disable auditing |
Turns off the audit service. | |
When perzone auditing is turned on, disables auditing in a non-global zone. | ||
9. (Optional) Reread auditing configuration changes |
Reads audit configuration changes into the kernel while the auditd daemon is running. |
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).
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.
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.
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.
Create dedicated audit partitions, as needed.
This step is most easily done during server installation. You can also create the partitions on disks that have not yet been mounted on the server. For complete instructions on how to create the partitions, see Chapter 11, Administering Disks (Tasks), in System Administration Guide: Devices and File Systems.
# newfs /dev/rdsk/cwtxdysz |
where /dev/rdsk/cwtxdysz is the raw device name for the partition.
If the local host is to be audited, also create an audit directory of last resort for the local host.
Create mount points for each new partition.
# mkdir /var/audit/server-name.n |
where server-name.n is the name of the server plus a number that identifies each partition. The number is optional, but the number is useful when there are many audit directories.
Add entries to automatically mount the new partitions.
Add a line to the /etc/vfstab file that resembles the following:
/dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes |
(Optional) Remove the minimum free space threshold on each partition.
If you use the default configuration, a warning is generated when the directory is 80 percent full. The warning removes the reason to reserve free space on the partition.
# tunefs -m 0 /var/audit/server-name.n |
Mount the new audit partitions.
# mount /var/audit/server-name.n |
Create audit directories on the new partitions.
# mkdir /var/audit/server-name.n/files |
Correct the permissions on the mount points and new directories.
# chmod -R 750 /var/audit/server-name.n/files |
On a file server, define the file systems to be made available to other hosts.
Often, disk farms are installed to store the audit records. If an audit directory is to be used by several systems, then the directory must be shared through the NFS service. Add an entry that resembles the following for each directory to the /etc/dfs/dfstab file:
share -F nfs /var/audit/server-name.n/files |
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 18, Managing Services (Overview), in System Administration Guide: Basic Administration and the smf(5) man page.
All systems that run the auditing service should have a local file system that can be used if no other file system is available. In this example, a file system is being added to a system that is named egret. Because this file system is only used locally, none of the steps for a file server are necessary.
# newfs /dev/rdsk/c0t2d0 # mkdir /var/audit/egret # grep egret /etc/vfstab /dev/dsk/c0t2d0s1 /dev/rdsk/c0t2d0s1 /var/audit/egret ufs 2 yes - # tunefs -m 0 /var/audit/egret # mount /var/audit/egret # mkdir /var/audit/egret/files # chmod -R 750 /var/audit/egret/files |
In this example, a new file system is created on two new disks that are to be used by other systems in the network.
# newfs /dev/rdsk/c0t2d0 # newfs /dev/rdsk/c0t2d1 # mkdir /var/audit/egret.1 # mkdir /var/audit/egret.2 # grep egret /etc/vfstab /dev/dsk/c0t2d0s1 /dev/rdsk/c0t2d0s1 /var/audit/egret.1 ufs 2 yes - /dev/dsk/c0t2d1s1 /dev/rdsk/c0t2d1s1 /var/audit/egret.2 ufs 2 yes - # tunefs -m 0 /var/audit/egret.1 # tunefs -m 0 /var/audit/egret.2 # mount /var/audit/egret.1 # mount /var/audit/egret.2 # mkdir /var/audit/egret.1/files # mkdir /var/audit/egret.2/files # chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files # grep egret /etc/dfs/dfstab share -F nfs /var/audit/egret.1/files share -F nfs /var/audit/egret.2/files # svcadm enable network/nfs/server |
In this example, the administrator runs the script command after the ZFS audit partitions are created. The following is the output of the command:
# zpool create auditf mirror c0t4d0 c0t5d0 # zfs create -o mountpoint=/audit auditf/audit # zfs create auditf/audit/noddy # zfs create auditf/audit/noddy/files # zfs create auditf/audit/blinken # zfs create auditf/audit/blinken/files # zfs set devices=off auditf/audit # zfs set exec=off auditf/audit # zfs set setuid=off auditf/audit # zfs set sharenfs=on auditf/audit # share - /audit/blinken/files rw "" - /audit/noddy rw "" - /audit/blinken rw "" - /audit/noddy/files rw "" - /audit rw "" # ^D script done on Fri Apr 10 10:10:20 2009 |
The administrator then views the mounts from the remote system, remotesys.
# dfshares remotesys RESOURCE SERVER ACCESS TRANSPORT remotesys:/audit/blinken/files remotesys - - remotesys:/audit/noddy remotesys - - remotesys:/audit/blinken remotesys - - remotesys:/audit/noddy/files remotesys - - remotesys:/audit remotesys - - |
Finally, the administrator mounts the /audit file system on /var/audit.
# mount remotesys:/audit /var/audit # ls /var/audit blinken noddy |
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:
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.
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 |
Audit policy determines the characteristics of the audit records for the local host. When auditing is enabled, the contents of the /etc/security/audit_startup file determine the audit policy.
You can inspect and change the current audit policy options with the auditconfig command. You can also modify the policy options to the auditconfig command in the audit_startup script to make permanent audit policy changes.
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).
Before auditing is enabled, the contents of the audit_startup file determine the audit policy:
#! /bin/sh ... /usr/bin/echo "Starting BSM services." /usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records /usr/sbin/auditconfig -conf Configures event-class mappings /usr/sbin/auditconfig -aconf Configures nonattributable events |
View the available policy options.
$ auditconfig -lspolicy |
The perzone and ahlt policy options can be set only in the global zone.
Enable or disable selected audit policy options.
# auditconfig -setpolicy prefixpolicy |
A prefix value of + enables the policy option. A prefix value of - disables the policy option.
Selects the policy to be enabled or to be disabled.
The policy is in effect until the next boot, or until the policy is modified by the auditconfig -setpolicy command.
For a description of each policy option, see Determining Audit Policy.
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 audit_startup entries disable the cnt policy option and enable the ahlt policy option across reboots:
# cat /etc/security/audit_startup #!/bin/sh /usr/bin/echo "Starting BSM services." /usr/sbin/deallocate -Is /usr/sbin/auditconfig -conf /usr/sbin/auditconfig -aconf /usr/sbin/auditconfig -setpolicy -cnt /usr/sbin/auditconfig -setpolicy +ahlt |
In this example, the auditd daemon is running and the ahlt audit policy has been set. The seq audit policy is added to the current policy. The seq policy adds a sequence token to every audit record. This is useful for debugging the auditing 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 auditconfig command puts the policy in effect until the next invocation of the command, or until the next boot.
$ auditconfig -setpolicy +seq $ auditconfig -getpolicy audit policies = ahlt,seq |
In this example, the perzone audit policy is set in the audit_startup script in the global zone. When a zone boots, the non-global zone collects audit records according to the audit configuration settings in its zone.
$ cat /etc/security/audit_startup #!/bin/sh /usr/bin/echo "Starting BSM services." /usr/sbin/deallocate -Is /usr/sbin/auditconfig -conf /usr/sbin/auditconfig -aconf /usr/sbin/auditconfig -setpolicy +perzone /usr/sbin/auditconfig -setpolicy +cnt |
In this example, the audit daemon is running and audit policy has been set. The auditconfig command changes the ahlt and cnt policies for the duration of the session. With these settings, audit records are dropped, but counted, when the audit file system is full. For restrictions on setting the ahlt policy, see Step 3.
$ auditconfig -setpolicy +cnt $ auditconfig -setpolicy -ahlt $ auditconfig -getpolicy audit policies = cnt,seq |
When the changes are put in the audit_startup file, the policies are permanently in effect:
$ cat /etc/security/audit_startup #!/bin/sh /usr/bin/echo "Starting BSM services." /usr/sbin/deallocate -Is /usr/sbin/auditconfig -conf /usr/sbin/auditconfig -aconf /usr/sbin/auditconfig -setpolicy +cnt |
The -ahlt option does not have to be specified in the file, because the ahlt policy option is disabled by default. This setting is appropriate when availability is more important than the security that audit records provide.
This procedure enables the audit service for all zones. To start the audit daemon in a non-global zone, see Example 30–20.
When auditing is configured securely, the system is in single-user mode until auditing is enabled. You can also enable auditing in multiuser mode.
You should perform this procedure as superuser after completing the following tasks:
Planning – Planning Solaris Auditing (Task Map)
Customizing audit files – Configuring Audit Files (Task Map)
Setting up audit partitions – How to Create Partitions for Audit Files
Setting up audit warning messages – How to Configure the audit_warn Email Alias
Setting audit policy – How to Configure Audit Policy
Host name translation must be working correctly for auditing to function. The hosts database in the naming services must be correctly configured and functioning.
For configuration of the hosts database, see the nsswitch.conf(4) and netconfig(4) man pages. For additional information, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+).
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.
Reboot the system.
# reboot |
The startup file /etc/security/audit_startup causes the auditd daemon to run automatically when the system enters multiuser mode.
Another effect of the script is to turn on device allocation. To configure device allocation, see Managing Device Allocation (Task Map).
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 |
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.
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–21.
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.
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.
Bring the system into multiuser mode.
# init 6 |
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.
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 |
This procedure restarts the auditd daemon when you have made changes to audit configuration files after the daemon has been running.
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).
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 |
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 |
Is the user ID.
Are the preselected audit classes.
For an example, see How to Modify a User's Preselection Mask.
To change audit policy on a running system, see Example 30–17.
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 |
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.
This procedure enables audits every zone identically. This method requires the least computer overhead and administrative resources.
Configure the global zone for auditing.
Complete the tasks in Configuring Audit Files (Task Map).
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.
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_startup or 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.
From the global zone, list the /etc/security directory in the non-global zone.
# ls /zone/zonename/etc/security/ |
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.
From the global zone, halt the non-global zone.
# zoneadm -z non-global-zone halt |
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 |
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.
In this example, the system administrator has modified the audit_class, audit_event, audit_control, audit_user, audit_startup, and audit_warn files.
The audit_startup and audit_warn files are read in the global zone only, so do 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.
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.
In the global zone, configure auditing, but do not enable the audit service.
Complete the tasks in Configuring Audit Files (Task Map).
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–18.
Do not enable the audit service. You enable the audit service after the non-global zones are configured for auditing.
In each non-global zone, configure the audit files.
If you are planning to disable auditing in the non-global zone, you can skip this step. To disable auditing, see Example 30–25.
Complete the tasks in Configuring Audit Files (Task Map).
Follow the procedures that are described in Configuring and Enabling the Audit Service (Task Map).
Do not configure system-wide audit settings.
Specifically, do not add the perzone or ahlt policy to the non-global zone's audit_startup file. And do not run the bsmconv command from the non-global zone.
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–20.
In the global zone, enable the audit service.
For the procedure, see How to Enable the Audit Service.
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 |
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. | |
Merge audit records |
Combines audit files from several machines into one audit trail. | |
Select records to examine |
Selects particular events for study. | |
Display audit records |
Enables you to view binary audit records. | |
Clean up incorrectly named audit files |
Provides an end timestamp to audit files that were inadvertently left open by the audit service. | |
Prevent audit trail overflow |
Prevents the audit file systems from becoming full. |
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.
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 bsmrecord command displays the audit event number, audit class, selection mask, and record format of an audit event.
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.
% bsmrecord -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 bsmrecord(1M) man page.
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.
% bsmrecord -p login 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 … |
In this example, the format of all audit records in the fd class are displayed.
% bsmrecord -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 … |
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/audit/server-name/files, the auditreduce command can find the output file without your specifying the full path.
This procedure applies only to binary audit records.
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).
Create a directory for storing merged audit files.
# mkdir audit-trail-directory |
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 .. |
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:
Selects all of the files in the audit trail.
Selects complete files only. This option ignores files with the suffix not_terminated.
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.
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.
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 |
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.
You can filter audit records for examination. For the complete list of filtering options, see the auditreduce(1M) man page.
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).
Select the kinds of records that you want from the audit trail, or from a specified audit file.
auditreduce -lowercase-option argument [optional-file] |
Specific argument that a lowercase option requires. For example, the -c option requires an argument of an audit class, such as ua.
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.
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.
Selects all of the events in a preselected audit class. The argument is an audit class name.
Selects all of the instances of a particular audit event. The argument is an audit event.
Is the name of an audit file.
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 |
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.
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.
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 |
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 |
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.
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).
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> |
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 |
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 |
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.
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.
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.
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 |
Lists files in subdirectories.
Lists files from most recent to oldest.
Lists the files in one column.
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 |
Remove the old not_terminated file.
# rm system-name old-not-terminated-file |
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.
If your security policy requires that all audit data be saved, do the following:
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.
Set up a schedule to delete the archived audit files from the audit file system.
Save and store auxiliary information.
Archive information that is necessary to interpret audit records along with the audit trail.
Keep records of which audit files have been archived.
Store the archived media appropriately.
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–30 and Example 30–34.
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.
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 can I reduce the amount of audit information that is being collected? |
Audit just the events that you want to audit. | |
How can I audit everything that a user does on the system? |
Audit one or more users for every command. | |
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 can I locate modifications to particular files? |
Audit file modifications, then use the auditreduce command to find particular files. | |
How can I reduce the size of my audit files? |
Limit the size of the binary audit file. | |
How can I remove audit events from the audit_event file? |
Update the audit_event file. | |
How can I audit all logins to a Solaris system? |
Audit logins from any system. | |
Why are auditing records not being kept for my FTP transfers? |
Use the appropriate auditing tool for utilities that generate their own logs. |
If you believe that auditing has been activated, but no audit records are in your primary audit directory, try the following.
You have correctly configured the hosts database in your naming service and it is functioning. To debug naming service problems, see the following:
nsswitch.conf(4) man page
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)
System Administration Guide: Naming and Directory Services (NIS+)
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.
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.
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.
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.
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 Oracle Solaris software 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.
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.
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.
If the previous steps did not indicate a problem, review the system log files, /var/adm/messages and /var/log/syslog.
Locate and fix the problems.
Then, if the audit service is running, restart it.
# audit -s |
If the audit service is not running, enable it.
For the procedure, see How to Enable the Audit Service.
After you have determined which events must be audited at your site, use the following suggestions to create manageable audit files.
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 |
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.
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.
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.
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.
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.
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 |
To record the arguments to commands, set the argv policy.
## audit_startup script ... 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 |
To record the environment in which the command is run, set the arge policy.
## audit_startup script ... 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 |
To record the arguments and the command environment, set both policies.
## audit_startup script ... auditconfig -setpolicy +argv auditconfig -setpolicy +arge ... |
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 |
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.
Audit the fw class.
Adding the class to the audit_user file generates fewer records than adding the class to the audit_control file.
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.
To read the filechg file, use the praudit command.
# /usr/sbin/praudit *filechg |
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.
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.
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.
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.
Change the user's preselection mask
Use one of the following two methods:
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 |
For maintenance purposes, sometimes a site wants to prevent audit events from being audited.
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.
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.
To update the preselection masks of users, follow the instructions in How to Modify a User's Preselection Mask.
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.
Starting in the Solaris 10 10/08 release, 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 |
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.
The Solaris OS can audit all logins, independent of source.
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 ... |
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.
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.
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.
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 |
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 |
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).
This section provides information about the following commands:
The following list summarizes the tasks of the auditd daemon:
Opens and closes audit files in the directories that are specified in the audit_control file. The files are opened in order of mention.
Loads one or more plugins. Sun provides two plugins. The audit_binfile.so plugin writes binary audit data to a file. The audit_syslog.so plugin delivers selected text summaries of audit records to the syslog log
Reads audit data from the kernel and outputs the data by using an auditd plugin.
Executes the audit_warn script to warn of various conditions. The binfile.so plugin executes the audit_warn script. The script, by default, sends warnings to the audit_warn email alias and to the console. The syslog.so plugin does not execute the audit_warn script.
By default, when all audit directories are full, processes that generate audit records are suspended. In addition, the auditd daemon writes a message to the console and to the audit_warn email alias. At this point, only the system administrator can fix the audit service. The administrator can log in to write audit files to offline media, delete audit files from the system, and do other cleanup tasks.
The audit policy can be reconfigured with the auditconfig command.
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. 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.
The audit command controls the actions of the auditd daemon. The audit command can do the following tasks:
Enable and disable auditing
Reset the auditd daemon
Write audit records to a different audit file
For a discussion of the available options, see the audit(1M) man page.
The bsmrecord 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 bsmrecord 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 bsmrecord command, see How to Display Audit Record Formats. Also, see the bsmrecord(1M) man page.
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:
Request audit records that were generated by specified audit classes
Request audit records that were generated by one particular user
Request audit records that were generated on specific dates
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.
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.
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.
Default – The praudit command with no options displays one audit token per line. The command displays the audit event by its description, such as the ioctl(2) system call. Any value that can be displayed as text is displayed in text format. For example, a user is displayed as the user name, not as the user ID.
–r option – The raw option displays as a number any value that could be numeric. For example, a user is displayed by user ID, Internet addresses are in hexadecimal format, and modes are in octal format. The audit event is displayed as its event number, such as 158.
–s option – The short option displays the audit event by its table name, for example, AUE_IOCTL. The option displays the other tokens as the default option displays them.
–x option – The XML option displays the audit record in XML format. This option is useful as input to browsers, or as input to scripts that manipulate XML.
The XML is described by a DTD that the audit service provides. Solaris software also provides a style sheet. The DTD and the style sheet are in the /usr/share/lib/xml directory.
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 |
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.
The auditconfig command provides a command-line interface to retrieve and set audit configuration parameters. The auditconfig command can do the following tasks:
Display, check, and configure audit policy
Determine if auditing is turned on or turned off
Turn auditing off and turn auditing on
Manage the audit directory and the audit file
Manage the audit queue
Get and set preselection masks
Get and set audit event to audit class mappings
Get and set configuration information, such as session ID and audit ID
Configure audit characteristics for a process, a shell, and a session
Reset audit statistics
For a discussion of the command options, see the auditconfig(1M) man page.
The audit service uses the following files:
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.
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.
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.
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.
flags keyword – Begins the entry that preselects which classes of events are audited for all users on the system. The audit classes that are specified here determine the system-wide audit preselection mask. The audit classes are separated by commas.
naflags keyword – Begins the entry that preselects which classes of events are audited when an action cannot be attributed to a specific user. The audit classes are separated by commas. The na event class belongs in this entry. The naflags entry can be used to log other event classes that are normally attributable but cannot be attributed. For example, if a program that starts at boot reads a file, then an fr in the naflags entry would create a record for that event.
minfree keyword – This keyword is deprecated. Use the p_minfree attribute to the audit_binfile.so plugin.
The p_minfree attribute defines the minimum free-space level for all audit file systems as a percentage. The percentage must be equal to 0 or greater than 0. The default is 20 percent. When an audit file system is 80 percent full, the audit data is then stored in the next available audit directory. For more information, see the audit_warn(1M) man page.
dir keyword – This keyword is deprecated. Use the p_dir attribute to the audit_binfile.so plugin.
The p_dir attribute lists the directory locations. Each line value defines an audit file system and directory that the system uses to store its audit files. You can specify one or more directory locations. The order of the values is significant. The auditd daemon creates audit files in the directories in the specified order. The first directory is the primary audit directory for the system. The second directory is the secondary audit directory where the auditd daemon creates audit files when the first directory becomes full, and so on. For more information, see the audit(1M) man page.
plugin keyword – Specifies the plugin path for the plugin modules audit_binfile.so and audit_syslog.so. The audit_binfile.so module handles the creation of binary audit files. The audit_syslog.so module provides real-time conversion of Solaris audit records to text. The audit classes that are specified in the p_flags attribute of the audit_syslog.so plugin must be a subset of the preselected audit classes.
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.
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 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 Solaris 10 release, the dir and minfree lines are deprecated. 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 |
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.
The /etc/security/audit_startup script automatically configures the auditing service when the system enters multiuser mode. The auditd daemon starts after the script performs the following tasks:
Configures the audit event-class mappings
Sets the audit policy options
For more information, see the audit_startup(1M) man page.
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:
By specifying audit classes that are always to be audited for this user
By specifying audit classes that are never to be audited for this user
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.
The always-audit-classes field turns on the auditing of the classes in that field. Use this field to modify system-wide settings. For example, putting all in the always-audit-classes field audits everything for a user.
The never-audit-classes field turns off the auditing of the classes in that field. Use this field to override system settings. Putting all in the never-audit-classes field turns off all auditing for the user, even the audit classes that are specified in the audit_control file.
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 |
Successful events and failed events are treated separately. A process could generate more audit records for failed events than for successful events.
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.
An audit directory has become more full than the minfree value allows. The minfree value or soft limit is a percentage of the available space on an audit file system.
The audit_warn script is invoked with the string soft and the name of the directory whose available space is below the minimum value. The auditd daemon switches automatically to the next suitable directory. The daemon writes the audit files in this new directory until the directory reaches its minfree limit. The auditd daemon then goes to each remaining directory in the order that is listed in the audit_control file. The daemon writes audit records until each directory is at its minfree limit.
All the audit directories have reached the minfree threshold.
The audit_warn script is invoked with the string allsoft. A message is written to the console. Email is also sent to the audit_warn alias.
When all audit directories that are listed in the audit_control file have reached their minfree threshold, the auditd daemon switches back to the first directory. The daemon writes audit records until the directory becomes completely full.
An audit directory has become completely full with no space remaining.
The audit_warn script is invoked with the string hard and the name of the directory. A message is written to the console. Email is also sent to the audit_warn alias.
The auditd daemon switches automatically to the next suitable directory with any space available. The auditd daemon goes to each remaining directory in the order that is listed in the audit_control file. The daemon writes audit records until each directory is full.
All the audit directories are completely full. The audit_warn script is invoked with the string allhard as an argument.
By default, a message is written to the console. Email is also sent to the audit_warn alias. Processes that would otherwise generate audit records continue to occur, but audit records are counted. Audit records are not generated. For an example of how to handle this situation, see Example 30–16 and How to Prevent Audit Trail Overflow.
An internal error occurs. Possible internal errors include the following:
A problem is discovered with the syntax of the audit_control file. By default, a message is sent to the console. Email is also sent 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.
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.
The Solaris OS provides rights profiles for configuring the audit service and for analyzing the audit trail.
Audit Control – Enables a role to configure Solaris auditing. This rights profile grants authorizations to configure files that are used by the audit service. The profile also enables a role to run audit commands. A role with the Audit Control profile can run the following commands: audit, auditd, auditconfig, bsmconv, and bsmunconv.
Audit Review – Enables a role to analyze Solaris audit records. This rights profile grants authorization to read audit records with the praudit and auditreduce commands. A role with this rights profile can also run the auditstat command.
System Administrator – Includes the Audit Review rights profile. A role with the System Administrator rights profile can analyze audit records.
To configure roles to handle the audit service, see Configuring RBAC (Task Map).
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: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
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.
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 classes (metaclass) |
|
no | ||
na |
Nonattributable events |
|
fr |
Read of data, open for reading |
|
fw |
Write of data, open for writing |
|
fa |
Access of object attributes: stat, pathconf |
|
fm |
Change of object attributes: chown, flock |
|
fc |
Creation of object |
|
fd |
Deletion of object |
|
cl | ||
ap |
Application-defined event |
|
ad |
Administrative actions (old administrative metaclass) |
|
am |
Administrative actions (metaclass) |
|
ss |
Change system state |
|
as |
System-wide administration |
|
ua |
User administration |
|
aa |
Audit utilization |
|
ps |
Process start and process stop |
|
pm |
Process modify |
|
pc |
Process (metaclass) |
|
ex |
Program execution |
|
io | ||
ip | ||
lo |
Login and logout events |
|
nt |
Network events: bind, connect, accept |
|
ot |
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.
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. |
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
The audit classes and their prefixes can be used in the following files and commands:
In the flags line in the audit_control file
In the plugin:name=audit_syslog.so; p_flags= line in the audit_control file
In the user's entry in the audit_user database
As arguments to auditconfig command options
See audit_control File for an example of using the prefixes in the audit_control file.
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 and audit_syslog.so.The plugins and their parameters can specify the following:
Where to send binary data, by using the audit_binfile.so plugin, p_dir parameter
The minimum space remaining on a disk before the administrator is warned, by using the audit_binfile.so plugin, p_minfree parameter
The maximum size of an audit file, by using the audit_binfile.so plugin, p_fsize parameter
The p_fsize parameter plugin is available starting in the Solaris 10 10/08 release.
A selection of audit records to be sent to syslog, by using the audit_syslog.so plugin, p_flags parameter
The maximum number of audit records that are queued for the plugin, by using the qsize parameter
Refer to the audit_binfile(5), audit_syslog(5), and audit_control(4) man pages.
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.
The following audit characteristics are set at initial login:
Process preselection mask – A combination of the audit classes from the audit_control file and the audit_user database. When a user logs in, the login process combines the preselected classes to establish the process preselection mask for the user's processes. The process preselection mask specifies whether events in each audit class are to generate audit records.
The following algorithm describes how the system obtains the user's process preselection mask:
(flags line + always-audit-classes) - never-audit-classes |
Add the audit classes from the flags line in the audit_control file to the classes from the always-audit-classes field in the user's entry in the audit_user database. Then, subtract from the total the classes from the user's never-audit-classes field.
Audit ID – A process acquires an audit ID when the user logs in. The audit ID is inherited by all child processes that were started by the user's initial process. The audit ID helps enforce accountability. Even after a user becomes root, the audit ID remains the same. The audit ID that is saved in each audit record always allows you to trace actions back to the original user who had logged in.
Audit Session ID – The audit session ID is assigned at login. The session ID is inherited by all child processes.
Terminal ID (port ID, machine address) – The terminal ID consists of the host name and the Internet address, followed by a unique number that identifies the physical device on which the user logged in. Most often, the login is through the console. The number that corresponds to the console device is 0.
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:
A host should have at least one local audit directory. The local directory can be used as a directory of last resort if the host is unable to communicate with the audit server.
Mount audit directories with the read-write (rw) option. When you mount audit directories remotely, also use the intr and noac options.
List the audit file systems on the audit server where they reside. The export list should include all systems that are being audited at the site.
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.
Audit files that are complete have names of the following form:
start-time.end-time.system |
Is the time that the first audit record in the audit file was generated
Is the time that the last record was written to the file
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.
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.
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.
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.
You can parse the binary data stream. To parse the data stream, you need to know the order of the fields in each token, and the order of tokens in each record. You also need to know the variants of an audit record. For example, the ioctl() system call creates an audit record for “Bad file name” that contains different tokens from the audit record for “Invalid file descriptor”.
For a description of the order of binary data in each audit token, see the audit.log(4) man page.
For a description of the order of tokens in an audit record, use the bsmrecord command. Output from the bsmrecord command includes the different formats that occur under different conditions. Square brackets ([]) indicate that an audit token is optional. For more information, see the bsmrecord(1M) man page. For examples, see also How to Display Audit Record Formats.
You can use the praudit command. Options to the command provide different text outputs. For example, the praudit -x command provides XML for input into scripts and browsers. praudit outputs do not include fields whose sole purpose is to help to parse the binary data. The outputs do not necessarily follow the order of the binary fields. Also, the order and format of praudit output is not guaranteed between Solaris releases.
For examples of praudit output, see How to View the Contents of Binary Audit Files, and the praudit(1M) man page.
For a description of the praudit output for each audit token, see the individual tokens in the Audit Token Formats section.
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 | |
arbitrary |
Data with format and type information | |
arg |
System call argument value | |
attribute |
File vnode tokens | |
cmd | ||
exec_args |
Exec system call arguments | |
exec_env |
Exec system call environment variables | |
exit |
Program exit information | |
file |
Audit file information | |
group |
Process groups information | |
groups |
Process groups information | |
header |
Indicates start of audit record | |
ip_addr |
Internet address | |
ip |
IP header information | |
ipc |
System V IPC information | |
ipc_perm |
System V IPC object tokens | |
iport |
Internet port address | |
opaque |
Unstructured data (unspecified format) | |
path |
Path information | |
path_attr |
Access path information | |
privilege |
Privilege set information | |
process |
Process token information | |
return |
Status of system call | |
sequence |
Sequence number token | |
socket |
Socket type and addresses | |
subject |
Subject token (same format as process token) | |
text |
ASCII string | |
trailer |
Indicates end of audit record | |
uauth |
Use of authorization | |
upriv |
Use of privilege | |
zonename |
Name of zone |
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.
The acl token records information about Access Control Lists (ACLs).
The acl token consists of four fixed fields:
A token ID that identifies this token as an acl token
A field that specifies the ACL type
An ACL value field
A field that lists the permissions associated with this ACL
The praudit -x command shows the fields of the acl token:
<acl type="1" value="root" mode="6"/> |
The arbitrary token encapsulates data for the audit trail. This token consists of four fixed fields and an array of data. The fixed fields are as follows:
A token ID that identifies this token as an arbitrary token
A suggested print format field, such as hexadecimal
An item size field that specifies the size of the data that is encapsulated, such as short
A count field that provides the number of following items
The remainder of the token is composed of count of the specified type. The praudit command displays the arbitrary token as follows:
arbitrary,decimal,int,1 42 |
The following table shows the possible values of the print format field.
Table 31–5 Values for the arbitrary Token's Print Format Field
Value |
Action |
---|---|
AUP_BINARY |
Prints the date in binary format |
AUP_OCTAL |
Prints the date in octal format |
AUP_DECIMAL |
Prints the date in decimal format |
AUP_HEX |
Prints the date in hexadecimal format |
AUP_STRING |
Prints the date as a string |
The following table shows the possible values of the item size field.
Table 31–6 Values for the arbitrary Token's Item Size Field
Value |
Action |
---|---|
AUR_BYTE |
Data is printed in units of bytes in 1 byte |
AUR_SHORT |
Data is printed in units of shorts in 2 bytes |
AUR_LONG |
Data is printed in units of longs in 4 bytes |
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 arg token has five fields:
A token ID that identifies this token as an arg token
An argument ID that tells which system call argument that the token refers to
The argument value
The length of the descriptive text string
The text string
The praudit -x command shows the fields of the arg token:
<argument arg-num="2" value="0x0" desc="new file uid"/> |
The attribute token contains information from the file vnode.
The attribute token has seven fields:
A token ID that identifies this token as an attribute token
The file access mode and type
The owner user ID
The owner group ID
The file system ID
The node ID
The device ID that the file might represent
For further information about the file system ID and the device ID, see the statvfs(2) man page.
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"/> |
The cmd token records the list of arguments and the list of environment variables that are associated with a command.
The cmd token contains the following fields:
A token ID that identifies this token as a cmd token
A count of the command's arguments
The argument list
The length of the next field
The content of the arguments
A count of the environment variables
The list of environment variables
The length of the next field
The content of the environment variables
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> |
The exec_args token records the arguments to an exec() system call. The exec_args token has two fixed fields:
A token ID field that identifies this token as an exec_args token
A count that represents the number of arguments that are passed to the exec() system call
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> |
The exec_args token is output only when the argv audit policy option is active.
The exec_env token records the current environment variables to an exec() system call. The exec_env token has two fixed fields:
A token ID field that identifies this token as an exec_env token
A count that represents the number of arguments that are passed to the exec() system call
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> |
The exec_env token is output only when the arge audit policy option is active.
The exit token records the exit status of a program. The exit token contains the following fields:
A token ID that identifies this token as an exit token
A program exit status as passed to the exit() system call
A return value that describes the exit status or that provides a system error number
The praudit command displays the exit token as follows:
exit,Error 0,0 |
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 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> |
This token has been replaced by the the groups token. See groups Token.
The groups token replaces the group token. The groups token records the group entries from the process's credential.
The groups token has two fixed fields:
A token ID field that identifies this token as a groups token
A count that represents the number of groups that are contained in this audit record
The remainder of this token is composed of count group entries.
The praudit -x command shows the fields of the groups token:
<group><gid>staff</gid><gid>other</gid></group> |
The groups token is output only when the group audit policy option is active.
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.
The header token has eight fields:
A token ID field that identifies this token as a header token
A byte count of the total length of the audit record, including both the header and the trailer tokens
A version number that identifies the version of the audit record structure
The audit event ID that identifies the audit event that the record represents
The ID modifier that identifies special characteristics of the audit event
The ID modifier field has the following flags defined:
0x4000 PAD_NOTATTR nonattributable event 0x8000 PAD_FAILURE failed audit event |
The address type, either IPv4 or IPv6
The machine's address
The time and date that the record was created
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"> |
The ip_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 in_addr token has three fields:
A token ID that identifies this token as an in_addr token
The IP address type, either IPv4 or IPv6
An IP address
The praudit -x command shows the content of the ip_addr token:
<ip_address>machine1</ip_address> |
The ip token contains a copy of an Internet Protocol header. The ip token has two fields:
A token ID that identifies this token as an ip token
A copy of the IP header, that is, all 20 bytes
The praudit command displays the ip token as follows:
ip address,0.0.0.0 |
The IP header structure is defined in the /usr/include/netinet/ip.h file.
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.
The ipc token has three fields:
A token ID that identifies this token as an ipc token
A type field that specifies the type of IPC object
The handle that identifies the IPC object
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–7 Values for the IPC Object Type Field
Name |
Value |
Description |
---|---|---|
AU_IPC_MSG |
1 |
IPC message object |
AU_IPC_SEM |
2 |
IPC semaphore object |
AU_IPC_SHM |
3 |
IPC shared-memory object |
The praudit -x command shows the fields of the ipc token:
<IPC ipc-type="shm" ipc-id="15"/> |
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 ipc_perm token has eight fields:
A token ID that identifies this token as an ipc_perm token
The user ID of the IPC owner
The group ID of the IPC owner
The user ID of the IPC creator
The group ID of the IPC creator
The access mode of the IPC
The sequence number of the IPC
The IPC key value
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.
The iport token contains the TCP or UDP port address.
The iport token has two fields:
A token ID that identifies this token as an iport token
The TCP or UDP port address
The praudit command displays the iport token as follows:
ip port,0xf6d6 |
The opaque token contains unformatted data as a sequence of bytes. The opaque token has three fields:
A token ID that identifies this token as an opaque token
A byte count of the data
An array of byte data
The praudit command displays the opaque token as follows:
opaque,12,0x4f5041515545204441544100 |
The path token contains access path information for an object.
The path token contains the following fields:
A token ID that identifies this token as an path token
The path length
The absolute path to the object that is based on the real root of the system
The praudit command displays the path token, without the second field, as follows:
path,/etc/security/audit_user |
The praudit -x command shows the content of the path token:
<path>/etc/security/audit_user</path> |
The following figure shows the format of a path 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 path_attr token contains the following fields:
A token ID that identifies this token as a path_attr token
A count that represents the number of sections of attribute file paths
count null-terminated strings
The praudit command displays the path_attr token as follows:
path_attr,1,attr_file_name |
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 privilege token contains the following fields:
A token ID that identifies this token as a privilege token
The length of the following field
The name of privilege set
The length of the following field
The list of privileges
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> |
The process token contains information about a user who is associated with a process, such as the recipient of a signal.
The process token has nine fields:
A token ID that identifies this token as a process token
The audit ID
The effective user ID
The effective group ID
The real user ID
The real group ID
The process ID
The audit session ID
A terminal ID that consists of a device ID and a machine address
The audit ID, user ID, group ID, process ID, and session ID are long instead of short.
The process token fields for the session ID, the real user ID, or the real group ID might be unavailable. The value is then set to -1.
Any token that contains a terminal ID has several variations. The praudit command hides these variations. So, the terminal ID is handled the same way for any token that contains a terminal ID. The terminal ID is either an IP address and port number, or a device ID. A device ID, such as the serial port that is connected to a modem, can be zero. The terminal ID is specified in one of several formats.
The terminal ID for device numbers is specified as follows:
32-bit applications – 4-byte device number, 4 bytes unused
64-bit applications – 8-byte device number, 4 bytes unused
In releases prior to the Solaris 8 release, the terminal ID for port numbers is specified as follows:
32-bit applications – 4-byte port number, 4-byte IP address
64-bit applications – 8-byte port number, 4-byte IP address
Since the Solaris 8 release, the terminal ID for port numbers is specified as follows:
32-bit with IPv4 – 4-byte port number, 4-byte IP type, 4-byte IP address
32-bit with IPv6 – 4-byte port number, 4-byte IP type, 16-byte IP address
64-bit with IPv4 – 8-byte port number, 4-byte IP type, 4-byte IP address
64-bit with IPv6 – 8-byte port number, 4-byte IP type, 16-byte IP address
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"/> |
The following figure shows the format of a process token.
The return token contains the return status of the system call (u_error) and the process return value (u_rval1).
The return token has three fields:
A token ID that identifies this token as a return token
The error status of the system call
The return value of the system call
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/"> |
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 sequence token has two fields:
A token ID that identifies this token as a sequence token
A 32-bit unsigned long field that contains the sequence number
The praudit command shows the field of the sequence token:
sequence,1292 |
The praudit -x command shows the content of the sequence token:
<sequence seq-num="1292"/> |
The sequence token is output only when the seq audit policy option is active.
The socket token contains information that describes an Internet socket. In some instances, the token has four fields:
A token ID that identifies this token as a socket token
A socket type field that indicates the type of socket referenced, either TCP, UDP, or UNIX
The local port
The local IP address
The praudit command displays this instance of the socket token as follows:
socket,0x0002,0x83b1,localhost |
In most instances, the token has eight fields:
A token ID that identifies this token as a socket token
The socket domain
A socket type field that indicates the type of socket referenced, either TCP, UDP, or UNIX
The local port
The address type, either IPv4 or IPv6
The local IP address
The remote port
The remote IP 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 command displays the socket token as follows:
socket,0x0002,0x0002,0x83cf,example1,0x2383,server1.Subdomain.Domain.COM |
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"/> |
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 has nine fields:
A token ID that identifies this token as a subject token
The audit ID
The effective user ID
The effective group ID
The real user ID
The real group ID
The process ID
The audit session ID
A terminal ID that consists of a device ID and a machine IP address
The audit ID, user ID, group ID, process ID, and session ID are long instead of short.
The subject token fields for the session ID, the real user ID, or the real group ID might be unavailable. The value is then set to -1.
Any token that contains a terminal ID has several variations. The praudit command hides these variations. So, the terminal ID is handled the same way for any token that contains a terminal ID. The terminal ID is either an IP address and port number, or a device ID. A device ID, such as the serial port that is connected to a modem, can be zero. The terminal ID is specified in one of several formats.
The terminal ID for device numbers is specified as follows:
32-bit applications – 4-byte device number, 4 bytes unused
64-bit applications – 8-byte device number, 4 bytes unused
In releases prior to the Solaris 8 release, the terminal ID for port numbers is specified as follows:
32-bit applications – 4-byte port number, 4-byte IP address
64-bit applications – 8-byte port number, 4-byte IP address
Since the Solaris 8 release, the terminal ID for port numbers is specified as follows:
32-bit with IPv4 – 4-byte port number, 4-byte IP type, 4-byte IP address
32-bit with IPv6 – 4-byte port number, 4-byte IP type, 16-byte IP address
64-bit with IPv4 – 8-byte port number, 4-byte IP type, 4-byte IP address
64-bit with IPv6 – 8-byte port number, 4-byte IP type, 16-byte IP address
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"/> |
The following figure shows the format of the subject token.
The text token contains a text string.
The text token has three fields:
A token ID that identifies this token as a text token
The length of the text string
The text string itself
The praudit -x command shows the content of the text token:
<text>booting kernel</text> |
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 trailer token has three fields:
A token ID that identifies this token as a trailer token
A pad number to aid in marking the end of the record
The total number of characters in the audit record, including both the header and trailer tokens
The praudit command displays the trailer token as follows:
trailer,136 |
The uauth token records the use of authorization with a command or action.
The uauth token contains the following fields:
A token ID that identifies this token as a uauth token
The length of the text in the following field
A list of authorizations
The praudit command displays the uauth token as follows:
use of authorization,solaris.admin.printer.delete |
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> |
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 zonename token contains the following fields:
A token ID that identifies this token as a zonename token
The length of the text in the following field
The name of the zone
The praudit -x command shows the content of the zonename token:
<zone name="graphzone"/> |