Audit (AU)

The Lightweight Audit Framework (LAF) is designed to be a CAPP compliant audit system for Linux. The subsystem allows configuring the events to be actually audited from the set of all events that are possible to be audited. Those events are configured in a specific configuration file and then the kernel is notified to build its own internal structure for the events to be audited.

6.2.3.1

Audit Configuration (AU.1)

The system administrator can define the events to be audited from the overall events that LAF is able to audit using rules defined in the /etc/audit.rules audit configuration file using simple filter expressions (AU1.1). This allows for a flexible definition of the events to be audited and the conditions under which events are audited. The system

administrator is also able to define a set of user IDs for which auditing is active (AU1.2) or alternatively a set of user IDs that are not audited (AU1.3). Changes to the audit configuration take effect when the audit daemon is notified about a change in the audit configuration (AU1.4).

This notification can only be performed by an administrative user (using the rcauditd script with the ‘reload’ parameter) (AU1.5).

The system adminstrator can select files to be audited by adding them to a watch list that is loaded into the kernel using the auditctl tool each time the audit system is started or reinitialized. The list allows the administrator to select an arbitrary audit tag value for each file which will be preserved as a searchable attribute in the audit log (AU1.6). The kernel interface for configuring these audit properties is usable only by root users (AU1.7).

This function contributes to satisfy the security requirements FAU_SEL.1 and FMT_MTD.1 (Management of audited events)

6.2.3.2

Audit Processing (AU.2)

Auditing is performed on a per process basis. A process can enable or disabling auditing for itself by attaching itself or detaching itself to the audit subsystem provided it is running with root privileges (AU2.1). The attribute of being attached to the audit subsystem is inherited by all processes that are forked off from a process, which ensures that events generated by child processes are also audited (AU2.2).

The kernel audits system calls in accordance with the rules defined in the audit.rules configuration file. Trusted processes can generate additional audit records and send them to the kernel (AU2.3). The login ID is associated with audit events ensuring that events can be easily associated with the ID a user used to log into the TOE (AU2.4). The events to be audited are forwarded by the kernel to an audit daemon, which writes the audit records to the audit trail. If the file system space does not have sufficient space to store new audit records or a configurable space

daemon (AU2.5). This ensures that audit records do not get lost due to resource shortage and the administrator can backup and clear the audit trail to free disk space for new audit logs.

The audit daemon appends audit records to a file whose name is specified in the audit configuration file (AU2.6). The audit configuration file can be used to execute administrator-specified notification actions when the free disk space available reaches an administrator-specified threshold (AU2.7). This is used to inform the system administrator that he needs to back-up the current audit trail and make space available for additional audit records. In the case the system administrator does not perform this in time and the available disk space is exhausted, the audit daemon can be configured to switch to single user mode or to halt the whole system (AU2.8). In that case the system administrator will need to back-up and clear the audit trail in single user mode and then re-boot the TOE in secure multiuser mode. Access to audit data by normal users is prohibited by the discretionary access control function of the TOE, which is used to restrict the access to the audit trail and audit configuration files to the system administrator only.

This function contributes to satisfy the security requirements FAU_SAR.2, FAU_STG.1, FAU_STG.3, FAU_STG.4 and FMT_MTD.1 (Management of the audit trail).

6.2.3.3

Audit Record Format (AU.3)

An audit record consists of one or more lines of text containing fields in a “keyword=value” tagged format. The following information is contained in all audit record lines:

• Type: indicates the source of the event, such as SYSCALL, FS_WATCH, USER, or LOGIN

• Timestamp: Date and time the audit record was generated

• Audit ID: unique numerical event identifier

• login ID (“auid”), the user ID of the user authenticated by the system (regardless if the user has changed his real and / or effective user ID afterwards)

• Effective user ID: the effective user ID of the process at the time the audit event was generated

• Success or failure (where appropriate) (AU3.1)

This information is followed by event specific data. In some cases, such as syscall event records involving file system objects, multiple text lines will be generated for a single event, these all have the same timestamp and audit ID to permit easy correlation.

Note: Although the TOE distinguishes between the effective and the filesystem user ID, those two are identical in all states of the TOE.

The event specific data will always contain data indicating if the request that caused the event has been successful or not (AU3.2).

The audit subsystem maintains a “Login ID” which is set when the user performs his initial login at a terminal or via a network connection (AU3.3). This Login ID is maintained for actions of this user until he terminates the session. This Login ID remains unchanged when the user performs a switch of the real and / or effective and filesystem user ID by the su command or by invoking a program that has the SUID bit set (AU3.4). This allows to trace all actions to the real user.

This function contributes to satisfy the security requirements FAU_GEN.1 and FAU_GEN.2

6.2.3.4

Audit Post­Processing (AU.4)

The TOE provides tools for managing ASCII files that can be used for post-processing of audit data. These tools include:

ausearch reads the ASCII audit data (AU4.1)

ausearch allows selective extraction of records from the audit trail using defined selection criteria (AU4.2)

The audit records are listed in chronological order by default. The sort utility can be used together with ausearch to use a different sorting order (AU.4.3).