5.6.3.1.4Socket call and IPC audit record generation
Some system calls pass an argument to the kernel specifying which function the system call is requesting from the kernel. These system calls request multiple services from the kernel through a single entry point. For example, the first argument to the ipc() call specifies whether the request is for semaphore operation, shared memory operation, and so forth. In the same manner, the socketcall() system call is a common kernel entry point for the socket system calls. The socketcall() and the ipc() call are extended to audit the arguments and therefore audit the exact service being performed. Following is a typical flow:
1.The kernel encounters a socketcall() or ipc() call.
2.The kernel invokes an audit framework function to collect appropriate data to be used in the auxiliary audit context.
3.The call is processed.
4.On exit the audit record that includes the auxiliary audit information is placed on the netlink.
5.6.3.1.5Record generation by trusted programs
Trusted programs create their own audit records in which their actions are described. The following describes a typical trusted program operation with respect to audit:
To begin auditing after a security relevant action, a trusted process opens the netlink socket, checks whether the audit is enabled, formats an audit message describing the action, then writes the audit message to the kernel. In turns, the kernel checks the user message filter list and, if appropriate, it sends the audit message back to auditd for logging.
Figure 5-75: User Space Record Generation
5.6.3.2Audit record format
Each audit record consist of record type, a time stamp, login ID, and process ID, along with variable audit data depending on the audit record type. In other words, the record depends on the audit event. Since audit records are written to
143
