[PATCH] loginuid change logging details

[Eric Paris]

On Mon, 2014-02-03 at 12:03 -0500, Steve Grubb wrote:
> On Monday, January 20, 2014 11:44:49 AM Eric Paris wrote:
> > 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.
> 
> Kernel maintainers have not added all the fields I have asked for at some 
> points. I think it was proposed to add a syscall record to everything which I 
> absolutely do not want to see. that is too much information.

Where did you ask?  That's the whole point of this e-mail, and I finish
reading your response and still don't know the answer...

> What is required is this:

> 2) who did it

This is the only part that we have question/inconsistency/stoopidity
with, that I can see.  But I still don't know how to solve it.

> #2 depends on which API the action occurred on and if we have a MAC subsystem 
> or not.

What does MAC have to do with it?

>  For netlink, we are limited to what rides along in the skb.

Not true. (this was true in the past, but not for years).  We (in
kernel) know everything about the task that sends a netlink message.

The place we have the least information is in the kaudit code storing
who sent a signal to auditd.  I'll avoid that nightmare though...

> For the 
> syscall interface, we have everything. For actions through /proc, we probably 
> can have everything.  Then there are various events embedded in the kernel 
> like the IMA events which trigger when they get loaded. So, what is necessary 
> to identify the subject? In descending order of importance: 

> auid, uid, ses, 
> tty, pid, subj, exe, comm, euid, gid, egid, everything else.

Ok, so you want these from every audit event?  All of these?  And these
are all that matter?  What does 'everything else' mean?  Do we want
more?  Do we not?

That's the point of the question.  What fields about the task doing an
operation should be included in events....

> > 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?
> 
> To save disk space. That is paramount. We cannot add syscall to everything 
> without eating up a lot of disk space. The main thing to remember is that 
> people who really use auditing never have enough disk space to keep everything 
> they want. So, we should always consider doing anything possible to minimize 
> disk usage no matter what.

Bam, back to senseless non-uniform mishmash mess....