RFE: MAC_STATUS 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, here is the current MAC_STATUS record:

# ausearch -m MAC_STATUS
time->Tue Aug 15 09:21:52 2017
type=MAC_STATUS msg=audit(1502803312.124:137): enforcing=1 old_enforcing=0 auid=0 ses=1

It seems odd that this isn't associated with a SYSCALL record, that is probably something we need to investigate. If this were associated with a SYSCALL record (which would have the missing information you are requesting), would that satisfy this requirement?

[pcmoore]

Also related to AUDIT_MAC_STATUS: #46.

[stevegrubb]

Yes, the issue is its lacking details about who sent it and how.

[pcmoore]

While looking into another issue, I realized that the reason this wasn't associated with a SYSCALL record was due to Fedora's default audit configuration which skips syscall auditing:

# auditctl -l
-a never,task

Enabling syscall auditing captures the associated SYSCALL record:

# auditctl -l
No rules
# ausearch -m MAC_STATUS
----
time->Wed Aug 16 09:45:25 2017
type=PROCTITLE msg=audit(1502891125.361:139): proctitle=736574656E666F7263650031
type=SYSCALL msg=audit(1502891125.361:139): arch=c000003e syscall=1 success=yes
exit=1  a0=3 a1=7fff19cee1d0 a2=1 a3=0 items=0 ppid=530 pid=581 auid=0 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="setenforce"
exe="/usr/sbin/setenforce" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=MAC_STATUS msg=audit(1502891125.361:139): enforcing=1 old_enforcing=0 auid=0
ses=1

@stevegrubb based on your comment above I'm guessing we can consider this resolved?

[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. There should not need to be a syscall record since this is not needing to be a compound event and sometimes the SYSCALL record is not there. The minimal required information should be in the MAC_CONFIG_STATUS record.

[pcmoore]

I left a similar comment in https://github.com/linux-audit/audit-kernel/issues/62#issuecomment-323097473, but I'll repeat it here ... 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 MAC_STATUS event?

This is a compound event, disconnecting the MAC_STATUS record from the SYSCALL record threatens existing users and isn't a change we are going to make. Knowing that you dislike information duplicated across records in a single event, I believe we have met the spirit of your original requirement, yes?

[rgbriggs]

More generally, how and who decides if an event is a compound SYSCALL or autonomous event? I don't believe this decision is so binary as presented. There are multiple events falling into this category that will frequently but not always have a SYSCALL record associated with it. Can we accommodate both so that the autonomous events are complete while possible to link this event with a SYSCALL event if it exists? This was part of the motivation for compiling the audit message list and augmenting it to include autonomous/compound flags in https://github.com/linux-audit/audit-documentation/issues/21

[pcmoore]

More generally, how and who decides if an event is a compound SYSCALL or autonomous event? I don't believe this decision is so binary as presented.

In this particular case, MAC_STATUS, the status quo is for this event to be accompanied by a SYSCALL record and I see not reason to change that, especially since the SYSCALL record happens to provide the information that is being requested.

[stevegrubb]

The problem is that the SYSCALL record does not show up all the time, Sometimes, I only get this:

type=MAC_STATUS msg=audit(1503404832.687:45): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295

There is no syscall record, its booted with audit=1, its missing a lot of detail. The record has to stand on its own.

[pcmoore]

I just redid my earlier testing to confirm, this time testing both with and without audit=1 on the kernel command line, as well as with syscall auditing both enabled and disabled.

Syscall auditing enabled, without audit=1 on the kernel command line:

# 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
# setenforce 1
# ausearch -i -m MAC_STATUS
----
type=PROCTITLE msg=audit(08/23/2017 17:23:47.012:123) : proctitle=setenforce 1 
type=SYSCALL msg=audit(08/23/2017 17:23:47.012:123) : arch=x86_64 syscall=write success=yes     
exit=1 a0=0x3 a1=0x7fff38f782c0 a2=0x1 a3=0x0 items=0 ppid=549 pid=575 auid=root uid=root     
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1     
comm=setenforce exe=/usr/sbin/setenforce subj=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 key=(null) 
type=MAC_STATUS msg=audit(08/23/2017 17:23:47.012:123) : enforcing=1 old_enforcing=0 
auid=root ses=1 

Syscall auditing enabled, with audit=1 on the kernel command line:

# 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 audit=1
# auditctl -l
No rules
# setenforce 1
# ausearch -i -m MAC_STATUS
----
type=PROCTITLE msg=audit(08/23/2017 17:26:56.848:129) : proctitle=setenforce 1 
type=SYSCALL msg=audit(08/23/2017 17:26:56.848:129) : arch=x86_64 syscall=write success=yes     
exit=1 a0=0x3 a1=0x7ffd69141e90 a2=0x1 a3=0x0 items=0 ppid=526 pid=552 auid=root uid=root     
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 
comm=setenforce exe=/usr/sbin/setenforce subj=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 key=(null) 
type=MAC_STATUS msg=audit(08/23/2017 17:26:56.848:129) : enforcing=1 old_enforcing=0 
auid=root ses=1 

Disabling syscall auditing reproduces what you are seeing:

# 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 audit=1
# auditctl -l
-a never,task
# setenforce 1
# ausearch -i -m MAC_STATUS
----
type=MAC_STATUS msg=audit(08/23/2017 17:33:40.160:139) : enforcing=1 old_enforcing=0 
auid=root ses=1 

Please confirm if you have syscall auditing enabled or disabled @stevegrubb, because right now this WORKSFORME and until you provide more information there is little I can do.

[stevegrubb]

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