[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ausearch on aggregation - syscall difference



LC Bruzenak wrote:
I have a test (virtual) machine running a 32-bit F9 OS.
My aggregating machine is a 64-bit F9 box.

source (32-bit machine) :

[root v1 ~]#  ausearch -ts today -i -a 10038
----
node=v1 type=SYSCALL msg=audit(10/24/2008 11:11:59.162:10038) : arch=i386 syscall=socketcall(recv) success=yes exit=5 a0=a a1=bfcc1f80 a2=25b0c4 a3=0 items=0 ppid=1 pid=11761 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=prelude-manager exe=/usr/bin/prelude-manager subj=system_u:system_r:prelude_t:s0-s15:c0.c1023 key=(null) node=v1 type=AVC msg=audit(10/24/2008 11:11:59.162:10038) : avc: denied { read } for pid=11761 comm=prelude-manager laddr=127.0.0.1 lport=4690 faddr=127.0.0.1 fport=36291 scontext=system_u:system_r:prelude_t:s0-s15:c0.c1023 tcontext=system_u:system_r:prelude_t:s15:c0.c1023 tclass=tcp_socket

aggregating machine (64-bit) :

[root dell1 ~]# ausearch -ts today -i -a 10038
----
node=v1 type=SYSCALL msg=audit(10/24/2008 11:11:59.162:10038) : arch=i386 syscall=getuid success=yes exit=5 a0=a a1=bfcc1f80 a2=25b0c4 a3=0 items=0 ppid=1 pid=11761 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=prelude-manager exe=/usr/bin/prelude-manager subj=system_u:system_r:prelude_t:s0-s15:c0.c1023 key=(null) node=v1 type=AVC msg=audit(10/24/2008 11:11:59.162:10038) : avc: denied { read } for pid=11761 comm=prelude-manager laddr=127.0.0.1 lport=4690 faddr=127.0.0.1 fport=36291 scontext=system_u:system_r:prelude_t:s0-s15:c0.c1023 tcontext=system_u:system_r:prelude_t:s15:c0.c1023 tclass=tcp_socket

Note that the syscall is listed differently.
This is using the 1.7.7 code (on F9), I have not yet moved over to 1.7.8
in case it may be fixed there.
This problem occurs because ausearch naively assumes the log data it's parsing originated on the same machine it's running on. Instead of reading the arch from the audit record it calls audit_detect_machine() which calls uname(). It then uses the machine arch it found with uname() to interpret the syscall number. Auparse has the same problem.

--
John Dennis <jdennis redhat com>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]