On Monday, January 20, 2014 11:44:49 AM Eric Paris wrote: 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. What is required is this: 1) when it happened 2) who did it 3) what did they act upon 4) what did they do 5) what was the result #1 is done automatically. #2 depends on which API the action occurred on and if we have a MAC subsystem or not. For netlink, we are limited to what rides along in the skb. 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. #3 is usually given by auxiliary records such as PATH, OBJ_PID, EXECVE, etc. They should include fields that make it possible to know exactly what was acted upon such as device, inode, ownership/group, permissions, object labels, or whatever it takes to know what was being manipulated depending on what it actually is. #4 is given by the event type. In cases where the event type is multiplexed, we need a op= field to say what operation is being performed. This is trusted information and never under attacker control and should never be logged as an untrusted string. In cases where there might be a space between words, just convert the space to a dash. #5 This is a simple res= field. That said...whatever we have right now, the audit utilities looks for that and only that. If we suddenly added a bunch of new fields, I still have to support all the mistakes of the past. The 2.x user space audit code supports all kernels since 2.6.16. Because there is no way to tell when features got added to what kernels, it will always have to support the whole mess. All of it. With or without the (proposed) new fields present. Because kernel maintainers didn't add it. 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. See above. HTH... -Steve

On Monday, February 03, 2014 12:43:50 PM Eric Paris wrote: 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. Because if its not a MAC system, there is no subject label. CAPP disavows any knowledge of labels. That's another place. That would have been nice. Its a pretty good list. There may be times when something else is important, but we'd probably need to see the event. 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. As many of the important ones as can be gotten in the same order for every record. 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