Re: [PATCH] loginuid change logging details
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(-)