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