ausearch on aggregation - syscall difference

ausearch on aggregation - syscall difference

[LC Bruzenak]

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.

Also, (at the latest) after F10 GA release I'll be migrating there.

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: ausearch on aggregation - syscall difference

[Steve Grubb]

On Friday 24 October 2008 13:08:41 LC Bruzenak wrote:
> Note that the syscall is listed differently.

Interesting.


> 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.

Nope...nothing was changed there to fix it. This is the first I'd heard of the 
problem..Can you show me the raw record?

ausearch -ts today -a 10038 --raw

Thanks,
-Steve

Re: ausearch on aggregation - syscall difference

[LC Bruzenak]

On Fri, 2008-10-24 at 13:16 -0400, Steve Grubb wrote:
> On Friday 24 October 2008 13:08:41 LC Bruzenak wrote:
> > Note that the syscall is listed differently.
> 
> Interesting.
> 
> 
> > 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.
> 
> Nope...nothing was changed there to fix it. This is the first I'd heard of the 
> problem..Can you show me the raw record?
> 
> ausearch -ts today -a 10038 --raw
> 
> Thanks,
> -Steve

I noticed it because with the audit-viewer I cannot see the "msg=" part
of TRUSTED_APP records. I submitted a bugtraq
(https://fedorahosted.org/audit-viewer/ticket/6) for that. So, that made
me look at the ausearch results to get all the info.

Additionally, I believe there is a policy issue which caused this in the
first place...

>From the aggregating machine:

[root@dell1 ~]# ausearch -ts today -a 10038 --raw
node=v1 type=AVC msg=audit(1224864719.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
node=v1 type=SYSCALL msg=audit(1224864719.162:10038): arch=40000003 syscall=102 success=yes exit=5 a0=a a1=bfcc1f80 a2=25b0c4 a3=0 items=0 ppid=1 pid=11761 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 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)


>From the originating machine:
[root@v1 ~]# ausearch -ts today -a 10038 --raw
node=v1 type=AVC msg=audit(1224864719.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 
node=v1 type=SYSCALL msg=audit(1224864719.162:10038): arch=40000003 syscall=102 success=yes exit=5 a0=a a1=bfcc1f80 a2=25b0c4 a3=0 items=0 ppid=1 pid=11761 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 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) 


So it looks like the architectures interpretation (-i) of the syscall is
where it differs?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: ausearch on aggregation - syscall difference

[LC Bruzenak]

On Fri, 2008-10-24 at 13:16 -0400, Steve Grubb wrote:
> On Friday 24 October 2008 13:08:41 LC Bruzenak wrote:
> > Note that the syscall is listed differently.
> 
> Interesting.
> 
> 
> > 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.
> 
> Nope...nothing was changed there to fix it. This is the first I'd heard of the 
> problem..Can you show me the raw record?
> 
> ausearch -ts today -a 10038 --raw
> 
> Thanks,
> -Steve
> 
[root@dell1 ~]# ausyscall 102
getuid
[root@dell1 ~]# ausyscall i386 102
socketcall

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: ausearch on aggregation - syscall difference

[John Dennis]

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>

Re: ausearch on aggregation - syscall difference

[Steve Grubb]

On Friday 24 October 2008 13:27:49 LC Bruzenak wrote:
> So it looks like the architectures interpretation (-i) of the syscall is
> where it differs?

Yes, there was a collision between the unset value and the i386 value in the 
source code. This meant that it when it ran across I386 machines, it thought 
there was an error looking it up and reverted to looking up the uname machine 
value as a fallback.  Svn commit 155 fixes this.

-Steve

Re: ausearch on aggregation - syscall difference

[LC Bruzenak]

On Fri, 2008-10-24 at 14:28 -0400, John Dennis wrote:
> >   
> 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.
> 

The audit-viewer gets the right syscall for the event's arch.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com