Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
1) For the *at syscalls, can we get the path from the FD being passed
to be
able to reconstruct what is being accessed?
You might sometimes be able to get A path. But every time anyone ever
says THE path they've already lost. There is no THE path. There might
be NO path. Every single request with THE path is always doomed to
fail.
2) For the adjtimex syscall, how do we only get events where the time
is set
rather than the clock being status'ed?
Now you want to match on stuff from 3) it's certainly possible... Not
necessarily going to be super easy, especially the rule definitions...
3) How do we select events to record based on values in structures
being
passed? (This is related to #2)
Same way you get the fd in a mmap record. AUX records.
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.)
watches do not work. watches can not work. watches are inode based.
all of /proc has one inode. I'm sure it's not completely unsolvable to
'watch' in proc, but it'll be a whole new thing JUST for proc...
8) Can we audit NFS based files? Samba?
Audit how? Audit changes made by THIS system? yes.
Audit changes made by the server or another client? no.
technologically impossible.
9) Can we get events for a watched file even when a user's
permissions do not
allow full path resolution?
No.
10) Can we optionally get events when a file is actually modified
rather than
when opened with intent to modify?
Possibly sometimes... It can't be completely reliable. Think about
mmap(). fsnotify_modify() tries to do something like this but it is
not reliable...
11) Why is the kernel dumping events into syslog instead of waiting
until the
queue is full when auditd shuts down for a restart?
Interesting thought...
13) Is audit by process name ready to go?
That's up to you/paul/richard.
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.
I disagree completely :)