[PATCH] loginuid change logging details

[Eric Paris]

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