Contents
Abstract
The Linux audit framework as shipped with this version of openSUSE provides a CAPP-compliant (Controlled Access Protection Profiles) auditing system that reliably collects information about any security-relevant event. The audit records can be examined to determine whether any violation of the security policies has been committed, and by whom.
Providing an audit framework is an important requirement for a CC-CAPP/EAL (Common Criteria-Controlled Access Protection Profiles/Evaluation Assurance Level) certification. Common Criteria (CC) for Information Technology Security Information is an international standard for independent security evaluations. Common Criteria helps customers judge the security level of any IT product they intend to deploy in mission-critical setups.
Common Criteria security evaluations have two sets of evaluation requirements, functional and assurance requirements. Functional requirements describe the security attributes of the product under evaluation and are summarized under the Controlled Access Protection Profiles (CAPP). Assurance requirements are summarized under the Evaluation Assurance Level (EAL). EAL describes any activities that must take place for the evaluators to be confident that security attributes are present, effective, and implemented. Examples for activities of this kind include documenting the developers' search for security vulnerabilities, the patch process, and testing.
This guide provides a basic understanding of how audit works and how it can be set up. For more information about Common Criteria itself, refer to the Common Criteria Web site.
Linux audit helps make your system more secure by providing you with a means to analyze what is happening on your system in great detail. It does not, however, provide additional security itself—it does not protect your system from code malfunctions or any kind of exploits. Instead, Audit is useful for tracking these issues and helps you take additional security measures, like Novell AppArmor, to prevent them.
Audit consists of several components, each contributing crucial functionality to the overall framework. The audit kernel module intercepts the system calls and records the relevant events. The auditd daemon writes the audit reports to disk. Various command line utilities take care of displaying, querying, and archiving the audit trail.
Audit enables you to do the following:
Audit maps processes to the user ID that started them. This makes it possible for the administrator or security officer to exactly trace which user owns which process and is potentially doing malicious operations on the system.
![]() | Renaming User IDs |
---|---|
Audit does not handle the renaming of UIDs. Therefore avoid renaming
UIDs (for example, changing |
Linux audit provides tools that write the audit reports to disk and translate them into human readable format.
Audit provides a utility that allows you to filter the audit reports for certain events of interest. You can filter for:
User
Group
Audit ID
Remote Hostname
Remote Host Address
System Call
System Call Arguments
File
File Operations
Success or Failure
Audit provides the means to filter the audit reports for events of interest and also to tune audit to record only selected events. You can create your own set of rules and have the audit daemon record only those of interest to you.
Audit reports are owned by root
and therefore only removable by
root
. Unauthorized users cannot remove the audit logs.
If the kernel runs out of memory, the audit daemon's backlog is exceeded, or its rate limit is exceeded, audit can trigger a shutdown of the system to keep events from escaping audit's control. This shutdown would be an immediate halt of the system triggered by the audit kernel component without any syncing of the latest logs to disk. The default configuration is to log a warning to syslog rather than to halt the system.
If the system runs out of disk space when logging, the audit system can be configured to perform clean shutdown (init 0). The default configuration tells the audit daemon to stop logging when it runs out of disk space.
The following figure illustrates how the various components of audit interact with each other:
Straight arrows represent the data flow between components while dashed arrows represent lines of control between components.
The audit daemon is responsible for writing the audit messages that
were generated through the audit kernel interface and triggered by
application and system activity to disk. How the audit daemon is
started is controlled by its configuration file,
/etc/sysconfig/auditd
. How the audit system
functions once it is started is controlled by
/etc/audit/auditd.conf
. For more information
about auditd and its configuration, refer to
Section 29.2, “Configuring the Audit Daemon”.
The auditctl utility controls the audit system. It controls the log generation parameters and kernel settings of the audit interface as well as the rule sets that determine which events are tracked. For more information about auditctl, refer to Section 29.3, “Controlling the Audit System Using auditctl”.
The file /etc/audit/audit.rules
contains a
sequence of auditctl commands that are loaded at system boot time
immediately after the audit daemon is started. For more information
about audit rules, refer to Section 29.4, “Passing Parameters to the Audit System”.
The aureport utility allows you to create custom reports from the audit event log. This report generation can easily be scripted, and the output can be used by various other applications, for example, to plot these results. For more information about aureport, refer to Section 29.5, “Understanding the Audit Logs and Generating Reports”.
The ausearch utility can search the audit log file for certain events using various keys or other characteristics of the logged format. For more information about ausearch, refer to Section 29.6, “Querying the Audit Daemon Logs with ausearch”.
The audit dispatcher daemon (audispd) can be used to relay event notifications to other applications instead of (or in addition to) writing them to disk in the audit log.
The autrace utility traces individual processes in a fashion similar to strace. The output of autrace is logged to the audit log. For more information about autrace, refer to Section 29.7, “Analyzing Processes with autrace”.