Solaris auditing keeps a record of how the system is being used. The auditing 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.What Is Auditing? How Does Auditing Work? How Is Auditing Related to Security? Audit Terminology and Concepts Auditing on a System With Zones Solaris Auditing Enhancements in the Solaris 10 Release 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). Basic Security Module (BSM)auditing Basic Security Module (BSM)device allocation audit tokensindividual audit token names audit logsaudit files classesaudit classes audit IDoverview IDsauditoverview user IDaudit ID and 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 su1M man page.The auditing 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.administeringauditingdescriptionAfter audit data is collected, 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. audit recordsevents that generateAuditing 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 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 records can also be logged by the syslog utility.audit_control fileoverviewaudit trailoverviewAudit files that are stored in binary format can be stored in a local partition. 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.syslog.conf fileaudit recordsaudit recordssyslog.conf fileAudit 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 Files. securityauditing and 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 auditing 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 auditing 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 auditing service. Some definitions include pointers to more complete descriptions.Term Definition Audit class audit classesdescriptionA 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 audit directorydescriptionA repository of audit files in binary format. For a description of the types of audit directories, see Audit Files. Audit event audit eventssummaryA 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 audit policydescriptionA 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 recordsdescriptionAudit 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 audit tokensdescriptionA 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 audit traildescriptionA collection of one or more audit files that store the audit data from all systems that run the auditing service. For more information, see Audit Trail. Preselection preselection in auditingauditingpreselection definitionaudit classespreselectionPreselection is the choice of which audit classes to monitor before you enable the auditing 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 public directoriesauditingpublic objectsauditingfilespublic objects audit trailno public objectsaudit class preselectioneffect on public objectsA 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. administeringauditingaudit eventsaudit classesdescriptionaudit eventsaudit_event fileaudit eventsdescriptionaudit_event filedescription/etc/security/audit_event fileaudit events andeventdescriptionSecurity-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_event4 man page.For example, the following entry defines the audit event for the exec system call:7:AUE_EXEC:exec(2):ps,exWhen 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. The exec system call can be attributed to a user, so the call is considered an attributable event. Events are nonattributable if the events occur at the kernel-interrupt level. Events that occur before a user is authenticated are also nonattributable. The na audit class handles audit events that are nonattributable. For example, booting the system is a nonattributable event.113:AUE_SYSTEMBOOT:system booted:naWhen 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 auditing service, third-party applications can generate audit events. Audit event numbers from 32768 to 65535 are available for third-party applications. administeringauditingaudit classes audit classesoverview 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 auditing 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_control4 man page. audit_user databaseexception to system-wide audit classesaudit classesexceptions to system-wide settingsUser-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 name service. The Solaris Management Console provides the graphical user interface (GUI) to administer the database. For details, see the audit_user4 man page. auditconfig commandaudit classes as argumentsDynamic 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 auditconfig1M 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 auditreduce1M 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-attributeaudit trailevents includedThere are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in the audit_class4 man page. audit classesmapping eventsaudit eventsmapping to classesmappingsevents to classes (auditing)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. administeringauditingaudit recordsaudit recordsoverviewEach 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,0The 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.audit tokensdescriptionFor 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.log4 man page. 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:otheraudit logsmodesaudit logscomparing binary and textuallog filesaudit recordsUDPusing for remote audit logsA site can store audit records in both formats. You can configure the systems at your site to use binary mode, or to use both modes. The following table compares 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 modeBrowser output in XML In real time, or searched by scripts that you have created for syslogPlain 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 is protected 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_syslog5 man page audit.log4 man page How to Configure syslog Audit Logs 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. The auditing 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. administeringauditingin zones managingauditing in zones auditingzones and configuringauditing in zones audit policysetting in global zone zonesauditing and zonesperzone audit policy perzone audit policywhen to use A zone is a virtualized operating system environment that is created within a single instance of the Solaris OS. The auditing 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 name 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 name 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. auditingchanges in current release new featuresauditing enhancements 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 Files. 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 auditd1M and auditconfig1M 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. audit tokensnew in current releaseFive audit tokens have been added:cmd audit tokenThe 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. path_attr audit tokenThe path_attr token records the sequence of attribute file objects that are below the path token object. For more information, see path_attr Token. privilege audit tokenThe privilege token records the use of privilege on a process. For more information, see privilege Token. uauth audit tokenThe uauth token records the use of authorization with a command or action. For more information, see uauth Token. zonename audit tokenThe 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: Virtualization Using the Solaris Operating System.