On Thu, May 14, 2020 at 7:30 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > Create a new audit record type to contain the subject information > when there are multiple security modules that require such data. > This record is emitted before the other records for the event, but > is linked with the same timestamp and serial number. > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > Cc: linux-audit@xxxxxxxxxx > --- With this patch, I see userspace audit records like this one: type=SYSTEM_BOOT msg=audit(1589816792.181:103): pid=789 uid=0 auid=4294967295 ses=4294967295 subj=? subj=system_u:system_r:init_t:s0 msg=' comm="systemd-update-utmp" exe="/usr/lib/systemd/systemd-update-utmp" hostname=? addr=? terminal=? res=success' I'm guessing that userspace is appending the second subj= field when it sees subj=? or otherwise is missing subj= information? Then we have kernel audit records like this: type=PROCTITLE msg=audit(1589816791.959:101): proctitle=2F7362696E2F617564697463 746C002D52002F6574632F61756469742F61756469742E72756C6573 type=SYSCALL msg=audit(1589816791.959:101): arch=c000003e syscall=44 success=yes exit=1056 a0=3 a1=7fff9ccc98a0 a2=420 a3=0 items=0 ppid=773 pid=783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=? key=(null) type=UNKNOWN[1420] msg=audit(1589816791.959:101): subj_selinux=system_u:system_r:unconfined_service_t:s0 subj_apparmor==unconfined type=CONFIG_CHANGE msg=audit(1589816791.959:101): auid=4294967295 ses=4294967295 subj=? op=add_rule key=(null) list=1 res=1 type=UNKNOWN[1420] msg=audit(1589816791.959:101): subj_selinux=system_u:system_r:unconfined_service_t:s0 subj_apparmor==unconfined where we are getting multiple copies of the new record type, one for each record type that had subj=?. Not sure what it is the audit folks want here. This is with multiple LSMs enabled; need to confirm that no change occurs if only one is enabled.
