On October 25, 2018 1:43:16 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2018-10-24 16:55, Paul Moore wrote: >> On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: >>> On 2018-10-19 19:16, Paul Moore wrote: >>>> On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > ... > >>>> However, I do care about the "op" field in this record. It just >>>> doesn't make any sense; the way you are using it it is more of a >>>> context field than an operations field, and even then why is the >>>> context important from a logging and/or security perspective? Drop it >>>> please. >>> >>> I'll rename it to whatever you like. I'd suggest "ref=". The reason I >>> think it is important is there are multiple sources that aren't always >>> obvious from the other records to which it is associated. In the case >>> of ptrace and signals, there can be many target tasks listed (OBJ_PID) >>> with no other way to distinguish the matching audit container identifier >>> records all for one event. This is in addition to the default syscall >>> container identifier record. I'm not currently happy with the text >>> content to link the two, but that should be solvable (most obvious is >>> taret PID). Throwing away this information seems shortsighted. >> >> It would be helpful if you could generate real audit events >> demonstrating the problems you are describing, as well as a more >> standard syscall event, so we can discuss some possible solutions. > > If the auditted process is in a container and it ptraces or signals > another process in a container, there will be two AUDIT_CONTAINER > records for the same event that won't be identified as to which record > belongs to which process or other record (SYSCALL vs 1+ OBJ_PID > records). There could be many signals recorded, each with their own > OBJ_PID record. The first is stored in the audit context and additional > ones are stored in a chained struct that can accommodate 16 entries each. > > (See audit_signal_info(), __audit_ptrace().) > > (As a side note, on code inspection it appears that a signal target > would get overwritten by a ptrace action if they were to happen in that > order.) As requested above, please respond with real audit events generated by this patchset so that we can discuss possible solutions. -- paul moore www.paul-moore.com
