audit_sockaddr

audit_ipc_perms

6.8.1.6.3Data structures

audit_sock: The netlink socket through which all user space communication is done.

audit_buffer: The audit buffer is used when formatting an audit record to send to user space. The audit subsystem pre-allocates audit buffers to enhance performance.

audit_context: The audit subsystem extends the task structure to potentially include an audit_context. On task creation, by default the audit context is built, unless specifically denied by the per-task filter rules. The audit subsystem further extends the audit_context to allow for more auxiliary audit information that may be needed for specific audit events. While the auxiliary information is collected during the execution of the system call, all other audit_context information is filled on entry and exit of the system call.

audit_filter_list: An array of filter lists to store various filter rules for various type of filters. Current filters supported are task creation time filter, syscall entry filter, syscall exit filter, file system watch filter, and user message filter.

audit_watch: A structure that holds audit information associated with an inode to watch.

watchlist: Per-directory list associated with directories that have watched children.

master_watchlist: A linked list that holds all the watches in the system.

auditfs_hash_table: A hash table of hashed inode addresses to store and retrieve inode audit data.

6.8.1.7Kernel subsystem device drivers

6.8.1.7.1External interfaces (system calls)

No direct interface.

Device driver-specific commands can be passed from a user-space program to the device driver using the ioctl system call, which is a system call of the File and I/O subsystem.

File and I/O first checks for some generic ioctl commands it can handle itself, and calls the device driver ioctl method if the request by the user program is not one of those generic requests. To issue an ioctl system call, the calling process must first have opened the device, which requires full access rights to the device itself. Those access checks are performed by the open system call within the File and I/O subsystem.

6.8.1.7.2Internal interfaces

Device drivers implement a set of methods that other kernel subsystems can directly use. In most cases, the File and I/O subsystem will use those methods after the processing of a user’s request, including checking the user’s right to perform the requested action. The internal interfaces are therefore the methods implemented by the various device drivers.

All checks, according to the security policy, have to be performed by the kernel subsystem, invoking a method of a specific device driver before it calls the function. For a description of the purpose of the device

229

Page 241
Image 241
IBM 10 SP1 EAL4 manual Kernel subsystem device drivers