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

[Steve Grubb]

On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
> On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
> > audit_log_task_info logs too much information for typical use. There are
> > times when you might want to know everything about what's connecting. But
> > in this case, we don't need anything about groups, saved uids, fsuid, or
> > ppid.
> > 
> > Its a shame we don't have a audit_log_task_info_light function which only
> > records:
> > 
> > pid= auid= uid= subj= comm= exe=  ses= tty=
> 
> This is getting back to my earlier concerns/questions about field ordering,
> or at the very least I'm going to hijack this conversation and steer it
> towards field ordering ;)

Field ordering is important. For example, suppose we decide to make ordering 
changes to the AUDIT_AVC record to bring it in line with current standards. 
Would anyone care?

> Before we go to much farther, I'd really like us to agree that ordering is
> not important, can we do that? 

Its kind of doubtful we can do anything like this quickly. Maybe over time. 
But for entirely new events, we can create some canonical order and use it.

> As a follow up, what do we need to do to make that happen in the userspace
> tools?

I have serious doubts that this is worth doing right now. To me, these are the 
burning issues that I think should be on the table to be solved rather than 
field ordering:

1) For the *at syscalls, can we get the path from the FD being passed to be
able to reconstruct what is being accessed?
2) For the adjtimex syscall, how do we only get events where the time is set
rather than the clock being status'ed?
3) How do we select events to record based on values in structures being
passed? (This is related to #2)
4) How do we select events when a setuid/setgid/setcapabilities file is
executed when you do not have a file list? IOW, extend perms to allow 
selection.
5) Can tty be added to AUDIT_LOGIN event?
6) How do we handle user names that are not in /etc/passwd? IOW, someone 
logins in as root through some network protocol, like spice, and perform admin 
actions with no local account.
7) Does audit of /proc work? If not can it? (Security parameters can be set
through it.)
8) Can we audit NFS based files? Samba?
9) Can we get events for a watched file even when a user's permissions do not
allow full path resolution?
10) Can we optionally get events when a file is actually modified rather than
when opened with intent to modify?
11) Why is the kernel dumping events into syslog instead of waiting until the 
queue is full when auditd shuts down for a restart?
12) The struct audit_status was extended to include version and 
backlog_wait_time. I cannot determine at runtime if they exist, meaning that 
software compiled on a new kernel runs on an old kernel, it will be reading 
random stack or heap to make decisions. The correct solution would be to make 
a new struct with planned expansion capability with version as the first 
element so any changes can be signaled. This new struct would be sent using a 
new netlink command.
13) Is audit by process name ready to go?

I really think some of these issues are more important than re-ordering event 
fields. There is also the issue of having some test suite for robustness.

-Steve