audispd audit-remote plugin and uid, gid, euid, suid, fsuid, egid, sgid, fsgid

[Steve Grubb]

On Thursday, November 13, 2014 02:51:28 PM Wojtczak Arkadiusz wrote:
> Hello,
> Lets assume that *id = uid or gid or euid or suid or fsuid or egid or sgid
> or fsgid. Audispd audit-remote (au-remote.conf) plugin sends native
> (numeric) uid, gid, euid, suid, fsuid, egid, sgid, fsgid. I want to
> correlate logs from many Linux boxes so I need to have *ids resolved to
> user/group names, similar to ausearch witch option "-interpret". Is there
> any way to enrich events with user/group names in au-remote or even earlier
> - in auditd or audit?

Not yet. I have been thinking about this and think I am settled on how to do 
this. (You can look at the auformat utility for some hints.) Just haven't 
tackled it yet due to other priorities. If you have a central uid database and 
use sssd or nscd rather than /etc/passwd, then you can probably achieve this.


> I've considered forking audit-remote to use auparse
> (injecting additional code somewhere near line 412 of audisp-remote.c) or
> doing something like "tail ... --follow audit.log | ausearch ... -i". Am I
> correct that to be 100% sure that user or group corresponds to appropriate
> *id the mapping process has to be done in the kernel?

No, but rather on the local machine. User name mappings is a user space 
phenomenon. The kernel only understands numbers. All interprettation is done 
in user space with trusted databases.


> Otherwise there is low probability that during the time gap between actual
> event and "ausearch -i" someone could change *id or user/group name. Any
> help would be appreciated.

They could unless use of those utilities are restricted. You could also setup 
a centralized user name management system to help things. But if you want to 
tackle this yourself, I think the uids, gids, and hostnames are the main 
things that need interpreting locally. Everything else can be done after the 
fact.

-Steve