On 2018-10-25 07:13, Paul Moore wrote: > 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. Ok, then we should be developping a test to test ptrace and signal auditting in general since we don't have current experience/evidence that those even work (or rip them out if not). > paul moore - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
