On 2020-10-22 21:21, Paul Moore wrote: > On Wed, Oct 21, 2020 at 12:39 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > Here is an exmple I was able to generate after updating the testsuite > > script to include a signalling example of a nested audit container > > identifier: > > > > ---- > > type=PROCTITLE msg=audit(2020-10-21 10:31:16.655:6731) : proctitle=/usr/bin/perl -w containerid/test > > type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) : contid=7129731255799087104^3333941723245477888 > > type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115583 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl > > type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) : contid=3333941723245477888 > > type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115580 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl > > type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) : contid=8098399240850112512^3333941723245477888 > > type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115582 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl > > type=SYSCALL msg=audit(2020-10-21 10:31:16.655:6731) : arch=x86_64 syscall=kill success=yes exit=0 a0=0xfffe3c84 a1=SIGTERM a2=0x4d524554 a3=0x0 items=0 ppid=115564 pid=115567 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=testsuite-1603290671-AcLtUulY > > ---- > > > > There are three CONTAINER_ID records which need some way of associating with OBJ_PID records. An additional CONTAINER_ID record would be present if the killing process itself had an audit container identifier. I think the most obvious way to connect them is with a pid= field in the CONTAINER_ID record. > > Using a "pid=" field as a way to link CONTAINER_ID records to other > records raises a few questions. What happens if/when we need to > represent those PIDs in the context of a namespace? Are we ever going > to need to link to records which don't have a "pid=" field? I haven't > done the homework to know if either of these are a concern right now, > but I worry that this might become a problem in the future. Good point about PID namespaces in the future but those accompanying records will already have to be conditioned for the PID namespace context that is requesting it, so I don't see this as a showstopper. I've forgotten about an important one we already hit, which is a network event that only has a NETFILTER_PKT record, but in that case, there is no ambiguity since there are no other records associated with that event. So the second is already an issue now. Using task_tgid_nr(current), in the contid testsuite script network event it attributed it to ping which caused the event, but we cannot use this since it wasn't triggered by a syscall and doesn't accurately reflect the kernel thread that received it. It could just be set to zero for network events. > The idea of using something like "item=" is interesting. As you > mention, the "item=" field does present some overlap problems with the > PATH record, but perhaps we can do something similar. What if we > added a "record=" (or similar, I'm not worried about names at this > point) to each record, reset to 0/1 at the start of each event, and > when we needed to link records somehow we could add a "related=1,..,N" > field. This would potentially be useful beyond just the audit > container ID work. Does it make any sense to use the same keyword in each type of record such as record/records as in PATH/SYSCALL: item/items ? (I prefer 0-indexed like item=...) > 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
