Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.

Mon May 9 21:03:47 UTC 2016

Performing the same test with a 32-bit binary on both a 32-bit and
64-bit host using the same, current kernel version would be helpful.

On Mon, May 9, 2016 at 4:54 PM, Kangkook Jee <aixer77 at gmail.com> wrote:
> Dear Paul,
>
> First of all, thanks a lot for your response.
>
> I think the problem that I have is that I can’t see expected message (which is AUDIT_SOCKCALL) from 64-bit kernel when it runs 32-bit binary that issues connect() system call.
> Regarding 32-bit system that I showed from the previous mail is just for a reference case to show normal behavior. For whatever kernel version,  I’m pretty sure it will produce a complete set of all 4 messages (1300, 1306, 1304, 1320).
>
> I think can run the same experiment from relatively newer version of kernel, but if what I see is true at least for a subset of kernel versions , I think it is still a problem.
> If you still have any specific item that you want me to perform, please let me know.
>
> Thanks for your help again!
>
> Regards, Kangkook
>
>
>> On May 9, 2016, at 4:15 PM, Paul Moore <paul at paul-moore.com> wrote:
>>
>> Without looking at the code too closely, have you tried doing these
>> tests on the same kernel version, preferably a current kernel?  The
>> test below is comparing 3.13 to 2.6.18 which might not be a valid
>> comparison, and even 3.13 is a few years old.
>>
>> On Fri, May 6, 2016 at 6:49 PM, Kangkook Jee <aixer77 at gmail.com> wrote:
>>> Hi, all
>>>
>>>
>>> This is a bump.
>>> Could any of you have a look into this case?
>>>
>>> Regards, Kangkook
>>>
>>> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77 at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04,
>>> 3.13.0-57-generic kernel - x86_64) typically issuing network related system
>>> calls which, in turn, would invoke the one of socketcall() system call.
>>>
>>> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304)  is
>>> reported when we run the 32-bit binary from a 64-bit machine. The following
>>> is the raw audit messages captured for connect() system from a 64-bit
>>> machine running 32-bit binary.
>>>
>>> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102
>>> success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269
>>> pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287
>>> egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn"
>>> exe="/home/accountname/32bit_test/conn" key=(null)
>>> MSG (1306): audit(1462273146.351:21482453):
>>> saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
>>> MSG (1320): audit(1462273146.351:21482453):
>>>
>>> And this is the raw audit message captured from a 32-bit machine (CentOS 5
>>> 2.6.18-404.el5 i686) running 32-bit binary.
>>>
>>> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102
>>> success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509
>>> pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>>> tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn"
>>> subj=user_u:system_r:unconfined_t:s0 key=(null)
>>> MSG (1306): audit(1462289555.340:807319):
>>> saddr=020000358A0F6D630000000000000000000000000000000000000000
>>> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
>>> MSG (1320): audit(1462289555.340:807319):•
>>>
>>> I hope you to catch the difference. While the first case does not report
>>> AUDIT_SOCKETCALL (1304) event, but the second case report the entry
>>> providing the list of arguments starting with "nargs=".
>>>
>>> Could you tell me whether this is an expected behavior? Or is there any way
>>> that I can fix it?
>>>
>>> I'm attaching the source code of the test program (conn.c) and summarizes
>>> the procedure to reproduce the problem. If you have any difficulty producing
>>> the issue, please let me know.
>>>
>>> 1. we added the following the audit rules from a 64-bit machine. It is
>>> intended to capture events from both 64-bit and 32-bit system calls.
>>>
>>> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S
>>> connect -S listen -S socket -S socketpair
>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>>>
>>> $ sudo auditctl -l
>>> LIST_RULES: exit,always arch=3221225534 (0xc000003e)
>>> syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>> syscall=socketcall
>>>
>>> 2. We added the following the audit rules from a 32-bit machine.
>>>
>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>>>
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>> syscall=socketcall
>>>
>>> 3. Build conn.c source and running
>>>  conn.c is a simple connection client.
>>>  $ cc -o conn conn.c
>>>  $ ./conn <remote_host> <port>
>>>
>>>  Example run
>>>
>>>  $ ./conn localhost 22
>>>  $ Please enter the message: this is random message
>>>    SSH-2.0-OpenSSH_4.3
>>>
>>> Thanks a lot for your help in advance.
>>>
>>>
>>> <conn.c>
>>>
>>>
>>>
>>> --
>>> Linux-audit mailing list
>>> Linux-audit at redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
>>
>>
>> --
>> paul moore
>> www.paul-moore.com
>
>
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

-- 
paul moore
security @ redhat