ausearch on aggregation - syscall difference

John Dennis jdennis at redhat.com
Fri Oct 24 18:28:02 UTC 2008


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 at 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 at 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 at redhat.com>




More information about the Linux-audit mailing list