Linux-audit Archive on lore.kernel.org
 help / color / Atom feed
* auditing signals
@ 2020-09-29 19:17 Richard Guy Briggs
  2020-10-08  0:55 ` Richard Guy Briggs
  0 siblings, 1 reply; 2+ messages in thread
From: Richard Guy Briggs @ 2020-09-29 19:17 UTC (permalink / raw)
  To: Linux-Audit Mailing List

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 <sgrubb@redhat.com> 2005-05-06 audit_signal_info AUDIT_TERM_INFO (single pid)                                                 
	e54dc2431d74 <amy.griffis@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@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 <rgb@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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: auditing signals
  2020-09-29 19:17 auditing signals Richard Guy Briggs
@ 2020-10-08  0:55 ` Richard Guy Briggs
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Guy Briggs @ 2020-10-08  0:55 UTC (permalink / raw)
  To: Linux-Audit Mailing List

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@redhat.com> 2005-05-06 audit_signal_info AUDIT_TERM_INFO (single pid)                                                 
> 	e54dc2431d74 <amy.griffis@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@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@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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-29 19:17 auditing signals Richard Guy Briggs
2020-10-08  0:55 ` Richard Guy Briggs

Linux-audit Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-audit/0 linux-audit/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-audit linux-audit/ https://lore.kernel.org/linux-audit \
		linux-audit@redhat.com
	public-inbox-index linux-audit

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.redhat.linux-audit


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git