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

[Eric Paris]

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   :)