Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

[Paul Moore]

On Tuesday, October 21, 2014 06:30:29 PM Eric Paris wrote:
> I've always hated the fact that we include this in ANY current audit
> message.  I truly believe we need two new record types.
> 
> AUDIT_PROCESS_INFO
> AUDIT_EXTENDED_PROCESS_INFO
> 
> What does my UID have to do with a syscall?  Why is it in the record?
> It's a pretty big change, like, RHEL8, but splitting the reporting of
> process info from other records will make all matter of things, in the
> kernel and in userspace so much cleaner...
> 
> Nuts:
> type=SYSCALL msg=audit(10/13/2014 03:07:39.919:117953) : arch=x86_64
> syscall=stat success=yes exit=0 a0=0x1332f60 a1=0x7fff8749e6d0
> a2=0x7fff8749e6d0 a3=0x0 items=1 ppid=28212 pid=30066 auid=root uid=root
> gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
> tty=(none) ses=367 comm=lsof exe=/usr/sbin/lsof
> subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=(null)
> 
> Slightly (and yes, just slightly) Less Nuts:
> type=SYSCALL msg=audit(10/13/2014 03:07:39.919:117953) : arch=x86_64
> syscall=stat success=yes exit=0 a0=0x1332f60 a1=0x7fff8749e6d0
> a2=0x7fff8749e6d0 a3=0x0 type=AUDIT_PROCESS_INFO msg=audit(10/13/2014
> 03:07:39.919:117953) : pid=30066 auid=root uid=root gid=root tty=(none)
> ses=367 comm=lsof exe=/usr/sbin/lsof
> subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=(null)
> type=AUDIT_EXTENDED_PROCESS_INFO msg=audit(10/13/2014 03:07:39.919:117953)
> : ppid=28212 euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
> key=(null)
> 
> It'd be weird is a syscall record actually only had syscall information....

I'm definitely in favor of this change.  We already have the concept of 
multiple records per event, we should use this to our advantage to make things 
a bit more sane.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/