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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
