Re: [PATCH v26 22/25] Audit: Add new record for multiple process LSM attributes
On 5/21/2021 1:19 PM, Paul Moore wrote:
<snip> and trim the CC list.
Okay, we've got a disconnect here regarding "audit
contexts" and
"local contexts", skip down below where I attempt to explain things a
little more but basically if there is a place that uses this pattern:
audit_log_start(audit_context(), ...);
This pattern isn't helpful. audit_context() returns NULL in about 1 of 4 calls.
All of these callers of audit_context() get a NULL result some of the time.
getname_kernel
debugfs_create_dir
tracefs_create_file
vfs_fchown
do_settimeofday64
bprm_execve
ksys_mmap_pgoff
move_addr_to_kernel
__do_pipe_flags
__do_sys_capset
syscall_trace_enter
cap_bprm_creds_from_file
load_module
__x64_sys_fsetxattr
bpf_prog_load
audit_signal_info_syscall
sel_write_enforce
common_lsm_audit
audit_set_loginuid
__dev_set_promiscuity
ipcperms
devpts_pty_new
... you don't need, or want, a "local context". You
might need a
local context if you see the following pattern:
audit_log_start(NULL, ...);
The "local context" idea is a hack and should be avoided whenever
possible; if you have an existing audit context from a syscall, or
something else, you *really* should use it ... or have a *really* good
explanation as to why you can not.
Almost all audit events want to record the subject context by calling
audit_log_task_context(). If multiple contexts need to be recorded
there has to be a separate record, which means there has to be an
audit context. The only case where an audit context is reliably available
is in syscalls. Hence, a "local context" for many of the cases where the
first argument to audit_log_start() would otherwise be NULL, either
explicitly or because audit_context() returns NULL.
Is there some other way to synchronize the "timestamp" without use of
an audit context? My understanding is that this is the primary purpose
of the audit context.