IBM 10 SP1 EAL4 manual Audit subsystem, Audit components, Spin locks, Kernel semaphores

5.5.5.3Spin locks

Spin locks provide an additional synchronization primitive for applications running on SMP systems. A spin lock is just a simple flag. When a kernel control path tries to claim a spin lock, it first checks whether or not the flag is already set. If not, then the flag is set, and the operation succeeds immediately. If it is not possible to claim a spin lock, then the current thread spins in a tight loop, repeatedly checking the flag until it is clear. The spinning prevents more than one thread of execution from entering the critical region at any one time.

5.5.5.4Kernel semaphores

A kernel semaphore is also a simple flag. If a kernel control path can acquire the semaphore, because the flag is not set, it proceeds with its normal operation. Otherwise, the corresponding process is suspended. It becomes runnable again once the semaphore is available. Semaphores are used to protect critical regions of code or data structures that allow just one process at a time to access critical regions of code and data; all other processes wishing to access this resource will be made to wait until it becomes free. The Linux kernel from version 2.6 provides mutex abstraction layer. For additional information on kernel mutexes, please see “Mutex Conundrum in the Linux Kernel,” http://developer.osdl.org/dev/mutexes/docs/MutexSIG.pdf.

5.6Audit subsystem

An auditing facility records information about actions that may affect the security of a computer system. In particular, an auditing facility records any action by any user that may represent a breach of system security. For each action, the auditing facility records enough information about those actions to verify the following:

•the user who performed the action

•the kernel object on which the action was performed

•the exact date and time it was performed

•the success or failure of the action

•the identity of the object involved

The TOE includes a comprehensive audit framework called Linux Audit Framework (LAF), which is composed of user-space and kernel-space components. The framework records security events in the form of an audit trail and provides tools to an administrative user to configure the subsystem and search for particular audit records, providing the administrator with the ability to identify attempted and realized violations of the system’s security policy.

This section describes the design and operation at a high level.

5.6.1Audit components

Figure 5-69illustrates the various components that make up the audit framework and how they interact with each other. In general, there are user-space components and kernel-space components that use a netlink socket for communication. Whenever a security event of interest occurs, the kernel queues a record describing the event and its result to the netlink socket. If listening to the netlink, the audit daemon, auditd, reads the record and writes it to the audit log.

This section describes the various components of the audit subsystem, starting with the kernel components and then followed by the user-level components.

131