RFE: MAC_POLICY_LOAD record cleanup

[stevegrubb]

This event should be a simple record with the following fields: pid, uid, auid, tty, session, context, comm, exe (in this order) + old value + new value if applicable.

[pcmoore]

For reference, the existing MAC_POLICY_LOAD record:

# ausearch -m MAC_POLICY_LOAD
time->Tue Aug 15 09:25:23 2017
type=PROCTITLE msg=audit(1502803523.246:263588): proctitle="/sbin/load_policy"
type=SYSCALL msg=audit(1502803523.246:263588): arch=c000003e syscall=1 success=yes 
  exit=3952426 a0=4 a1=7f04918b6000 a2=3c4f2a a3=0 items=0 ppid=2124 pid=2130
  auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1
  comm="load_policy" exe="/usr/sbin/load_policy"
  subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=MAC_POLICY_LOAD msg=audit(1502803523.246:263588): policy loaded auid=0 ses=1

The information you are requesting is already present via the SYSCALL record in the event; the one possible exception being the "old value" and "new value", but I'm not sure this is something we can audit (you wouldn't want us to dump the entire SELinux policy via an audit record, would you?).

So my question is this: are you satisfied with the information already present in the SYSCALL record, or do you want it duplicated in the MAC_POLICY_LOAD record? In the past you have complained about information duplicated across records in the same audit event, are you not worried about the same thing happening here?

[pcmoore]

Also related to AUDIT_MAC_POLICY_LOAD: #47.

[stevegrubb]

For reference, this is what I see: type=MAC_POLICY_LOAD msg=audit(1502852854.102:43): policy loaded auid=4294967295 ses=4294967295

Very different from yours. :-) This is all I see - every event. It should not need a syscall record attached.

[pcmoore]

Well that's interesting :)

I just ran some quick tests and it would appear the difference is likely due to Fedora's default audit configuration which disables syscall auditing:

# auditctl -l
-a never,task
# > /var/log/audit/audit.log 
# load_policy 
# ausearch -m MAC_POLICY_LOAD
----
time->Wed Aug 16 09:40:16 2017
type=MAC_POLICY_LOAD msg=audit(1502890816.464:135): policy loaded auid=0 ses=1
# auditctl -D
No rules
# load_policy
# ausearch -m MAC_POLICY_LOAD
----
time->Wed Aug 16 09:40:16 2017
type=MAC_POLICY_LOAD msg=audit(1502890816.464:135): policy loaded auid=0 ses=1
----
time->Wed Aug 16 09:40:43 2017
type=PROCTITLE msg=audit(1502890843.665:138): proctitle="load_policy"
type=SYSCALL msg=audit(1502890843.665:138): arch=c000003e syscall=1 success=yes     
exit=3866253 a0=4 a1=7fd9dbbcb000 a2=3afe8d a3=0 items=0 ppid=530 pid=575 auid=0 uid=0 
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="load_policy" 
exe="/usr/sbin/load_policy" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key=(null)
type=MAC_POLICY_LOAD msg=audit(1502890843.665:138): policy loaded auid=0 ses=1

With that mystery solved, I'm going to revisit my previous question: are you satisfied with the information present in the SYSCALL record? If not, are you okay with the information being duplicated in both the SYSCALL and MAC_POLICY_LOAD records? I know field duplication across records in the same event has been a source of concern for you in the past.

[rgbriggs]

This is exactly the same situation with NETFILTER_CFG records. If you want an autonomous record only, then set the audit context to "NULL" in the audit_log_start() call.

[pcmoore]

I don't think it's quite the same situation as the NETFILTER_CFG records as this was due to the Fedora default configuration disabling syscall auditing.

Regardless, I believe the associated SYSCALL record provides the information @stevegrubb is asking for and I suspect we will be able to close this as NOTABUG (my guess is @stevegrubb didn't realize he was tripping over the Fedora defaults).

[rgbriggs]

See point 3: https://github.com/linux-audit/audit-kernel/issues/25#issuecomment-301891179

[pcmoore]

The NETFILTER_CFG record situation is complicated by the missing audit_dummy_context() check which is why I said this isn't quite the same situation, at the moment this appears to be purely a configuration issue.

[stevegrubb]

I always run with audit=1 on boot prompt and the full STIG setup. The STIG rules is what the majority of the people use and its how we should all be testing.

[pcmoore]

If you've got auditing partially disabled there is little we can do. @stevegrubb can you confirm your audit configuration and the resulting MAC_POLICY_LOAD event?

[stevegrubb]

Paul, I have worked on audit for 13 years. I am not misconfiguring my system. This is what I get:

ausearch --start today -m MAC_POLICY_LOAD --just-one -i

type=MAC_POLICY_LOAD msg=audit(08/22/2017 08:27:13.243:46) : policy loaded auid=unset ses=unset

No detail.

[pcmoore]

Since you've worked on audit for 13 years @stevegrubb I don't need to tell you what my testing below shows:

Test with syscall auditing enabled:

# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.13.0-0.rc6.git0.1.4.secnext.fc28.x86_64 root=UUID=dd832653-d03d-431b-
9e3a-1a8f17dba5ef ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us nomodeset 
console=ttyS0 LANG=en_US.UTF-8
# auditctl -l
No rules
# load_policy
# ausearch --start today -m MAC_POLICY_LOAD --just-one -i
----
type=PROCTITLE msg=audit(08/23/2017 17:38:50.993:128) : proctitle=load_policy 
type=SYSCALL msg=audit(08/23/2017 17:38:50.993:128) : arch=x86_64 syscall=write success=yes 
exit=3866289 a0=0x4 a1=0x7f6f820a0000 a2=0x3afeb1 a3=0x0 items=0 ppid=553 pid=587 auid=root     
uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 
comm=load_policy exe=/usr/sbin/load_policy subj=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 key=(null) 
type=MAC_POLICY_LOAD msg=audit(08/23/2017 17:38:50.993:128) : policy loaded auid=root ses=1 

Test with syscall auditing disabled:

# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.13.0-0.rc6.git0.1.4.secnext.fc28.x86_64 root=UUID=dd832653-d03d-431b-
9e3a-1a8f17dba5ef ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us nomodeset 
console=ttyS0 LANG=en_US.UTF-8
# auditctl -l
-a never,task
# load_policy
# ausearch --start today -m MAC_POLICY_LOAD --just-one -i
----
type=MAC_POLICY_LOAD msg=audit(08/23/2017 17:43:02.173:133) : policy loaded auid=root ses=1 

This remains WORKSFORME, your ball @stevegrubb.

[pcmoore]

I had a thought over the weekend, and after digging a bit today it appears to be true. Unfortunately. See #66, but the basic idea is that we are not enabling syscall auditing for init/systemd, even if we specify auditd=1 on the kernel command line. This doesn't really resolve the information in the SYSCALL record vs MAC_POLICY_LOAD record, but it would explain why one might see a MAC_POLICY_LOAD record without a SYSCALL record. Unfortunately it took some time to arrive at this conclusion, if Steve had provided more information about the circumstances surrounding his lone MAC_POLICY_LOAD record we might have found this sooner.

[stevegrubb]

This appears to be fixed by https://github.com/linux-audit/audit-kernel/issues/66