On Wed, May 6, 2020 at 6:43 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2020-05-06 17:26, Steve Grubb wrote: > > On Wednesday, April 29, 2020 5:32:47 PM EDT Richard Guy Briggs wrote: > > > On 2020-04-29 14:47, Steve Grubb wrote: > > > > On Wednesday, April 29, 2020 10:31:46 AM EDT Richard Guy Briggs wrote: > > > > > On 2020-04-28 18:25, Paul Moore wrote: > > > > > > On Wed, Apr 22, 2020 at 5:40 PM Richard Guy Briggs <rgb@xxxxxxxxxx> > > > > > > > > wrote: > > > > > > > Some table unregister actions seem to be initiated by the kernel to > > > > > > > garbage collect unused tables that are not initiated by any > > > > > > > userspace > > > > > > > actions. It was found to be necessary to add the subject > > > > > > > credentials > > > > > > > to cover this case to reveal the source of these actions. A > > > > > > > sample > > > > > > > record: > > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : > > > > > > > table=nat > > > > > > > family=bridge entries=0 op=unregister pid=153 uid=root auid=unset > > > > > > > tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 > > > > > > > comm=kworker/u4:2 exe=(null)> > > > > > > > > > > > > [I'm going to comment up here instead of in the code because it is a > > > > > > bit easier for everyone to see what the actual impact might be on the > > > > > > records.] > > > > > > > > > > > > Steve wants subject info in this case, okay, but let's try to trim > > > > > > out > > > > > > some of the fields which simply don't make sense in this record; I'm > > > > > > thinking of fields that are unset/empty in the kernel case and are > > > > > > duplicates of other records in the userspace/syscall case. I think > > > > > > that means we can drop "tty", "ses", "comm", and "exe" ... yes? > > > > > > > > > > From the ghak28 discussion, this list and order was selected due to > > > > > Steve's preference for the "kernel" record convention, so deviating > > > > > from this will create yet a new field list. I'll defer to Steve on > > > > > this. It also has to do with the searchability of fields if they are > > > > > missing. > > > > > > > > > > I do agree that some fields will be superfluous in the kernel case. > > > > > The most important field would be "subj", but then "pid" and "comm", I > > > > > would think. Based on this contents of the "subj" field, I'd think > > > > > that "uid", "auid", "tty", "ses" and "exe" are not needed. > > > > > > > > We can't be adding deleting fields based on how its triggered. If they > > > > are unset, that is fine. The main issue is they have to behave the same. > > > > > > I don't think the intent was to have fields swing in and out depending > > > on trigger. The idea is to potentially permanently not include them in > > > this record type only. The justification is that where they aren't > > > needed for the kernel trigger situation it made sense to delete them > > > because if it is a user context event it will be accompanied by a > > > syscall record that already has that information and there would be no > > > sense in duplicating it. > > > > We should not be adding syscall records to anything that does not result from > > a syscall rule triggering the event. Its very wasteful. More wasteful than > > just adding the necessary fields. > > So what you are saying is you want all the fields that are being > proposed to be added to this record? > > If the records are all from one event, they all should all have the same > timestamp/serial number so that the records are kept together and not > mistaken for multiple events. One reason for having information in > seperate records is to be able to filter them either in kernel or in > userspace if you don't need certain records. Yes, I'm opposed to duplicating fields across records in a single event. If there are cases where we have a standalone record, such as with "unregister", then there is an argument to be made about duplicating some fields that are important in the standalone unregister case. However, this is *only* for those fields which make sense in the standalone kernel unregister event; if the field isn't useful in this unregister corner case *and* it is duplicated in another record type which normally accompanies this record in an event there is no reason it needs to be in this record. > > I also wished we had a coding specification that put this in writing so that > > every event is not a committee decision. That anyone can look at the document > > and Do The Right Thing ™. > > > > If I add a section to Writing-Good-Events outlining the expected ordering of > > fields, would that be enough that we do not have long discussions about event > > format? I'm thinking this would also help new people that want to contribute. To be clear, we are not changing any existing record formats; they are part of the kernel/userspace ABI and changing them would break the ABI. In a perfect world both the audit kernel and userspace would have been designed, implemented, and documented better. Unfortunately it wasn't and we have to live with what we have. -- paul moore www.paul-moore.com
