auditing signals
Richard Guy Briggs
rgb at redhat.com
Thu Oct 8 00:55:48 UTC 2020
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 <sgrubb at redhat.com> 2005-05-06 audit_signal_info AUDIT_TERM_INFO (single pid)
> e54dc2431d74 <amy.griffis at 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 <viro at 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 <rgb at 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
More information about the Linux-audit
mailing list