I think this just touches the surface of what be/have been done. There appears to be no logic, consistency, or predictability to audit logs. They are a piecemeal mish mash of information. Every record has whatever fields it has, not because there is some coherent reason, but because that's what somebody accidentally put in there when the record was created.
This is a great example. The only things we log are the pid and uid. The information in the uid field is actually useless (given the uid==new-auid but anyway) but clearly for searching reasons it makes sense. But, why is pid and uid enough? Why not selinux context? Why not ppid? Why not all of the *id's (gid, fsuid, etc.) Why not comm? why not tty? What is the minimal set of information we should be sending with every record that uniquely identifies a process? Why is every record it's own little world? I know we grew organically to get here, but I'd really like to find a consistent usable future... Maybe we don't need everything from a syscall record in every record, but there is some meaningful subset which identifies a process and user. What is that subset? On Fri, 2014-01-17 at 18:34 -0500, Richard Guy Briggs wrote: > I missed posting this before the holidays. I discovered this while adding > other information to other message types. > > It seemed to me that loginuid changes were significantly missing context > references. This patch adds that. Is this sufficient, or is there more > information missing too? If this is sufficient, stop reading this cover > letter > and review the patch. If it is not sufficient, keep reading below... > > The question has been raised that perhaps we should be switching this to use > audit_log_task_info() istead which adds a whole lot more information about > this > task. > > In the existing message > pid > uid > are already given, before > old-auid > new-auid > old-ses > new-ses > . > > The function audit_log_task_info() gives: > ppid > pid > auid > uid > gid > euid > suid > fsuid > egid > sgid > fsgid > tty > ses > comm > exe > res > . > > So, > pid > uid > are in the right order, along with > new-auid (auid) > new-ses (ses) > but if we give the > old-auid > old-ses > values first, then call audit_log_task_info(), the old values will preceed > pid > uid > . > > Is this re-ordering acceptable to gain more information and reduce code > duplicity? > > > Richard Guy Briggs (1): > audit: log task context when setting loginuid > > kernel/auditsc.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
