Fw: audit syscall information.

Debora Velarde dvelarde at us.ibm.com
Fri Apr 29 17:29:14 UTC 2005





Just in case this one came out in html too, this should be only in text.

----- Forwarded by Debora Velarde/Austin/IBM on 04/29/2005 12:27 PM -----

Debora Velarde/Austin/IBM wrote on 04/28/2005 03:39:09 PM:

> In our syscalls, we are currently checking the expected values of
> some of the syscall parameters.  We do not always check a0, a1, a2,
> and a3.  One syscall may check a0, a1, and a2.  Another may only
> check a0, and a1.
>
> When we compile our syscalls in 32bit mode on a 64bit system, the
> a0, a1, a2, a3 values are no longer what we expected them to be.
>
> For example, in our access syscall test
>  a0 = pathname
>  a1 = mode
>
> When we compile and run in 64bit mode:
> The audit record looks like:
> type=KERNEL msg=audit(1114696605.916:2151478): item=0 name=".
> /mytest.9825" inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0 rdev=00:00
> type=KERNEL msg=audit(1114696605.916:2151478): syscall=21
> arch=c000003e success=yes exit=0 a0=50a460 a1=4 a2=3cb762ea03 a3=0
> items=1 pid=9825 loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 comm="access_test"
> exe=/deb/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/filters/access_test
>
> From our test:
> access_test    0  INFO  :  expected (pfilename) a0 s=./mytest.9825
> h=50a460 d=5284960 u=5284960.  (expected a0 printed as a string,
> hex, decimal, unsigned values)
>   Note audit record a0=50a460 which matches expected value printed in hex
>
> access_test    0  INFO  :  expected (access_mode) a1 h=4 d=4 u=4.
> (expected a1 printed as a hex, decimal, and unsigned value)
>   Note audit record a1=4 which matches expected (printed in %x, %d, and
%u)
>
> access_test    0  INFO  :  expected (pfilename) objectname
s=./mytest.9825.
>   Matches "name" in audit record"
>
> access_test    1  PASS  :  Expected record found!
>
> When we compile and run in 32bit mode:
> type=KERNEL msg=audit(1114696996.822:2260436): item=0 name=".
> /mytest.10196" inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0
rdev=00:00
> type=KERNEL msg=audit(1114696996.822:2260436): syscall=33
> arch=40000003 success=yes exit=0 a0=80510e0 a1=76c378 a2=0 a3=0
> items=1 pid=10196 loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 comm="access_test"
> exe=/deb/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/filters/access_test
>
> From our test
> access_test    0  INFO  :  expected (pfilename) a0 s=./mytest.10196
> h=8051260 d=134550112 u=134550112.
>  Note audit record a0=80510e0 does NOT match expected (in %x, %d, or
> %u format).
>
> access_test    0  INFO  :  expected (access_mode) a1 h=4 d=4 u=4.
>  Note audit record a1=76c378.  does NOT match expected (in %x , %d,
> or %u format).
>
> access_test    0  INFO  :  expected (pfilename) objectname
s=./mytest.10196.
>
> access_test    1  FAIL  :  Expected record not found.
>
> I know David put some hooks in for the ipc syscalls, I haven't been
> able to test those to see if that corrects this problem for those or
> not.  I'm not sure when that fix was introduced.  I'm currently
> running on kernel.2.6.9-5.0.3.EL.audit.20 and this problem is true
> for the ipc syscalls as well.
>
> If that does fix the problem, should our tests only check a0, a1,
> a2, a3 values for the syscalls which David is adding these hooks?
>
> Thanks,
> debbie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050429/ad4cec66/attachment.htm>


More information about the Linux-audit mailing list