[PATCH] loginuid change logging details

[Steve Grubb]

On Monday, February 03, 2014 12:43:50 PM Eric Paris wrote:
> 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...

On this mail list years ago, IRC, telecons, all over. Besides, I shouldn't be 
the only one pointing this stuff out. Whoever is maintaining this really needs 
to understand it and just fix it....along time ago.


> > 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?

Because if its not a MAC system, there is no subject label. CAPP disavows any 
knowledge of labels.


> >  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...

That's another place.

> > 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?

That would have been nice.

> All of these?  And these are all that matter?

Its a pretty good list. There may be times when something else is important, 
but we'd probably need to see the event.


>  What does 'everything else' mean?  Do we want
> more?  Do we not?

Everything else as in fsuid and minor permissions. Those are important in a 
syscall related to opening a file, but is wasting disk space for any other 
syscall. IOW, just adding a syscall record like has been done in the past just 
wastes disk space.

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

As many of the important ones as can be gotten in the same order for every 
record.


> > > 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....

No. Why do you say that? You can add a helper function that records those 
fields in a specific order and simply doesn't add a syscall record which eats a 
lot of space.

What I am trying to say is that this needed to be fixed a long time ago. Just 
moving stuff around and adding fields arbitrarily messes up parsing and slows 
down searching big files. Any time you do this, I also have to add logic to 
conditionally support searching as stuff gets added and that makes a mess of 
user space code.

-Steve