Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
4:21 p.m.
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.
5:49 p.m.
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(a)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>
3:15 p.m.
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(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
3:54 p.m.
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(a)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(a)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(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
4:03 p.m.
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(a)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(a)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(a)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(a)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(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> paul moore
> www.paul-moore.com
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
security @ redhat
4:02 p.m.
Dear Paul,
As you requested, I installed ubuntu 14.04 system for both 32bit and 64bit systems and
update their kernel version to the latest and I still see the problem occurring.
Here’s how I reproduced the problem. Currently, kernel version for those systems are
white-lab0@ubuntu-32bit:~/32bit_test$ uname -a
Linux ubuntu-32bit 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:45:15 UTC 2015
i686 i686 i686 GNU/Linux
white-lab0@ubuntu-64bit:/tmp$ uname -a
Linux ubuntu-64bit 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux
I ran the same experiment and captured logs from both system.
* Ubuntu 64 bit system
white-lab0@ubuntu-64bit:/tmp$ grep -A3 -e "syscall=102.*a0=3" /tmp/audit.log
...
MSG (1300): audit(1462912875.581:31612): arch=40000003 syscall=102 success=yes exit=0 a0=3
a1=ff9ec540 a2=f7599000 a3=ffffffff items=0 ppid=2193 pid=2433 auid=1000 uid=1000 gid=1000
euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=2
comm="conn" exe="/home/white-lab0/32bit_test/conn" key=(null)
MSG (1306): audit(1462912875.581:31612): saddr=020000357F0001010000000000000000
MSG (1327): audit(1462912875.581:31612): proctitle="-bash"
MSG (1320): audit(1462912875.581:31612):
...
* Ubuntu 32 bit system
white-lab0@ubuntu-32bit:~/32bit_test$ grep -A4 -n -e "syscall=102.*a0=3"
/tmp/audit.log
--
2395:MSG (1300): audit(1462913073.096:5616): arch=40000003 syscall=102 success=yes exit=0
a0=3 a1=bff7f4d0 a2=b75a6000 a3=ffffffff items=0 ppid=3486 pid=3543 auid=1000 uid=1000
gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=2
comm="conn" exe="/home/white-lab0/32bit_test/conn" key=(null)
2396-MSG (1304): audit(1462913073.096:5616): nargs=3 a0=4 a1=8dc37a0 a2=10
2397-MSG (1306): audit(1462913073.096:5616): saddr=020000357F0001010000000000000000
2398-MSG (1327): audit(1462913073.096:5616): proctitle="-bash"
2399-MSG (1320): audit(1462913073.096:5616):
--
As you see from above, while Ubuntu 32 bit system could see 1304 messages, Ubuntu 64bit
system is still failing to received the message.
Please take a look at this issue and please let me know if you need any more information.
Thanks for your help in advance
Regards, Kangkook
On May 9, 2016, at 5:03 PM, Paul Moore <pmoore(a)redhat.com>
wrote:
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(a)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(a)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(a)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(a)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(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
>>
>>
>> --
>> paul moore
>> www.paul-moore.com
>
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
security @ redhat
5:20 p.m.
On Tue, May 10, 2016 at 5:02 PM, Kangkook Jee <aixer77(a)gmail.com> wrote:
Dear Paul,
As you requested, I installed ubuntu 14.04 system for both 32bit and 64bit systems and
update their kernel version to the latest and I still see the problem occurring.
Hello,
Thank you for reporting this problem and your help in reproducing the
problem on a system with similar kernels. I'm not sure how quickly we
will be able to address this issue, but I've added it to our issue
tracker, you can follow the progress at the link below.
* https://github.com/linux-audit/audit-kernel/issues/14
--
paul moore
www.paul-moore.com
3156
days inactive
3162
days old
linux-audit@lists.linux-audit.osci.io
6 comments
3 participants
participants (3)
-
Kangkook Jee -
Paul Moore -
Paul Moore