Re: [PATCH v26 22/25] Audit: Add new record for multiple process LSM attributes

From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>
Cc: casey.schaufler@intel.com, selinux@vger.kernel.org,
	linux-audit@redhat.com, keescook@chromium.org,
	john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v26 22/25] Audit: Add new record for multiple process LSM attributes
Date: Tue, 25 May 2021 10:28:37 -0700	[thread overview]
Message-ID: <39d6ac53-d965-de64-266f-d0fa3139e52f@schaufler-ca.com> (raw)
In-Reply-To: <CAHC9VhSdFVuZvThMsqWT-L9wcHevA-0yAX+kxqXN0iMmqRc10g@mail.gmail.com>

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. 