IBM 10 SP1 EAL4 Manuale Utente
•
audit_sockaddr
•
audit_ipc_perms
6.8.1.6.3 Data 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
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 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.
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.7 Kernel subsystem device drivers
6.8.1.7.1 External 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.
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.
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.2 Internal 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
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