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.

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

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

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?

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.

Thanks!

- 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

Reply via email to