On 2020-09-29 15:17, Richard Guy Briggs wrote: > Hello auditors and auditees... > > Have you got any rules or tests to test audit logging signals or ptrace? > > I thought I understood how it worked, but it appears I need to signal a task > group.
Ok, I got a hint elsewhere and was able to produce what I was looking for... > I was a little less sure of how to trigger a ptrace audit log, but also > figured that out. > > I wrote up an audit-testsuite test case to test it and it made two seperate > sys_kill calls which generated two events rather than the one I was looking > for to fill the aux_pids structure. > > > https://github.com/linux-audit/audit-testsuite/compare/master...rgbriggs:ghat81-test-signal-ptrace > > It is essentially: > > sleep 5& t1=$! > sleep 5& t2=$! > auditctl -a always,exit -F arch=b64 -S kill -F key=testkill > kill -TERM $t1 $t2 > sleep 1 > auditctl -d always,exit -F arch=b64 -S kill -F key=testkill > sleep 2 # let the queue drain > ausearch -ts recent -i -k testkill Here's a recipe that produces what I was looking for: auditctl -a exit,always -F arch=b64 -S kill -F key=kill; perl -e " setpgrp || die; fork || sleep 10; fork || sleep 10; sleep 10"& pid=$!; sleep 1; kill TERM -$pid; auditctl -d exit,always -F arch=b64 -S kill -F key=kill; ausearch -ts recent -i -k kill -m OBJ_PID > The output looks something like this when I was hoping for one event with two > OBJ_PID records. > > type=PROCTITLE msg=audit(04/08/2019 06:58:12.308:277) : proctitle=bash -l > type=OBJ_PID msg=audit(04/08/2019 06:58:12.308:277) : opid=6104 oauid=root > ouid=root oses=3 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > ocomm=sleep > type=SYSCALL msg=audit(04/08/2019 06:58:12.308:277) : arch=x86_64 > syscall=kill success=yes exit=0 a0=0x17d8 a1=SIGTERM a2=0x0 a3=0x7f119b4919c0 > items=0 ppid=6066 pid=6083 auid=root uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=bash > exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=testkill > ---- > type=PROCTITLE msg=audit(04/08/2019 06:58:12.308:278) : proctitle=bash -l > type=OBJ_PID msg=audit(04/08/2019 06:58:12.308:278) : opid=6105 oauid=root > ouid=root oses=3 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > ocomm=sleep > type=SYSCALL msg=audit(04/08/2019 06:58:12.308:278) : arch=x86_64 > syscall=kill success=yes exit=0 a0=0x17d9 a1=SIGTERM a2=0x0 a3=0x7f119b4919c0 > items=0 ppid=6066 pid=6083 auid=root uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=bash > exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=testkill And the output I was seeking: ---- type=PROCTITLE msg=audit(10/07/2020 20:38:04.322:4109) : proctitle=-bash type=OBJ_PID msg=audit(10/07/2020 20:38:04.322:4109) : opid=72551 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl type=OBJ_PID msg=audit(10/07/2020 20:38:04.322:4109) : opid=72548 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl type=OBJ_PID msg=audit(10/07/2020 20:38:04.322:4109) : opid=72550 oauid=root ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl type=SYSCALL msg=audit(10/07/2020 20:38:04.322:4109) : arch=x86_64 syscall=kill success=yes exit=0 a0=0xfffee49c a1=SIGTERM a2=0x55f62915d3a0 a3=0x8 items=0 ppid=484 pid=506 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=kill ---- > Now the trick is how to trigger more than one OBJ_PID record in a single > syscall, which was the original goal of the exercise. It looks like it might > need to be a signal sent to a process group with more than one task or a task > that has threaded. > > Can anyone suggest a simple test preferrably using our audit-testsuite perl > infrasructure to get more than one OBJ_PID record? I've got this working in the audit-testsuite case above. > The code in question was introduced: > c2f0c7c356dc <sgr...@redhat.com> 2005-05-06 audit_signal_info > AUDIT_TERM_INFO (single pid) > e54dc2431d74 <amy.grif...@hp.com> 2007-03-29 ("[PATCH] audit signal > recipients") (multi-pid) > When auditing syscalls that send signals, log the pid > and security context for each target process. > Optimize the data collection by adding a counter for > signal-related rules, and avoiding allocating an aux struct unless we have > more than one target process. > > > For process groups, collect pid/context data in > blocks of 16. > > Move the audit_signal_info() hook up in > check_kill_permission() so we audit attempts where permission is denied. > > a5cb013da773 <v...@zeniv.linux.org.uk> 2007-03-20 ("[PATCH] auditing > ptrace") > > As a bit of an aside, it occurs to me that there could be information > overwritten if signal information was stored before ptrace information stored > since ptrace uses the context->target_* slot directly whereas signals check > to see if that slot is used first and then overflows to the context->aux_pids > structure. If the ptrace information is always guaranteed to come first or > alone, there is no issue. > > If you are still reading this far, the interest in this arose from trying to > find a way to connect potentially multiple OBJ_PID records with different > CONTAINER_ID records in the ghak90 Audit Container ID patchset rather than > using the op= field. As you can see, there are now three OBJ_PID records in the event. Next step is to add this to the ghat64 contid test, then to assign a different audit contaienr identifier to each and have each generate a CONTAINER_ID record that can't be differentiated. The obvious field addition to the CONTAINER_ID record would be opid. > Thanks! > > - RGB - RGB -- Richard Guy Briggs <r...@redhat.com> 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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
