Red Hat Bugzilla – Bug 140085
LTC9536-bind audit produces wrong audit record.
Last modified: 2007-11-30 17:07:05 EST
Hardware Environment: Software Environment: Steps to Reproduce: 1. add the following filter entry to /etc/audit/filter.conf: syscall bind = always; 2. reload or stop and start auditd 3. run: aurun nc -l -p 3333 -s 127.0.0.1 Actual Results: 2004-06-21T20:11:02 9 853 root bind("[sock:af=2,type=1]", [TRUNCATED SOCKADDR: len=0], 16); result=0 Expected Results: 2004-06-21T20:12:17 7 1565 root bind("[sock:af=2,type=1]", 127.0.0.1:3333, 16); result=0 Additional Information: Glen, please mirror this bug to Red Hat. Created an attachment (id=5057) fix off-by-one that causes wrong argument to be decoded backported bugfix from 2.6 LAuS code, the original code incorrectly decoded the wrong argument for T_opaque pointers. Created an attachment (id=5058) patch tlo "laus" source code (liblaussrv) to print port numbers properly After the kernel fix (see previous patch), the syscall is audited properly, but the tools don't print it correctly; there is no separator printed between the address and the port number: root bind("[sock:af=2,type=1]", 127.0.0.13333, 16); result=0 The attached patch to the "laus" package adds a colon before the port number: root bind("[sock:af=2,type=1]", 127.0.0.1:3333, 16); result=0 Created an attachment (id=5059) fix for 32bit socketcall audit on 64bit platforms the socketcall decoding logic assumed that the userspace sizeof(long) is equal to the kernel's sizeof(long), which is wrong in the case of 32bit programs running on a 64bit architecture. The attached patch keeps the behavior unchanged for 32/32 or 64/64 syscalls, but adds a workaround for 32bit code running on 64bit kernels. ---------- Action by: Glen Johnson Issue Registered ---------- Action by: Glen Johnson Status set to: Waiting on Tech File uploaded: audit-bind-kernel.diff ---------- Action by: Glen Johnson File uploaded: audit-bind-liblaussrv.diff ---------- Action by: Glen Johnson File uploaded: audit-opteron-bind32.diff ---------- Action by: Glen Johnson ----- Additional Comments From spwoods@us.ibm.com 2004-06-21 20:19 ------- ---------- Action by: Glen Johnson ----- Additional Comments From khoa@us.ibm.com 2004-06-22 13:17 ------- We'll close this bug report once Red Hat has fixed this in an official RHEL3 release. ---------- Action by: Glen Johnson ----- Additional Comments From khoa@us.ibm.com 2004-06-22 13:56 ------- *** Bug 9279 has been marked as a duplicate of this bug. *** ---------- Action by: bjohnson Mike, This one been around awhile....any update ? I've asked peterm to take a look. Category set to: Applications ---------- Action by: mgahagan Peterm is waiting for this one, patches attached. Issue escalated to Support Engineering Group by: mgahagan. mgahagan assigned to issue for IBM-LTC. ---------- Action by: jantill Issue escalated to Sustaining Engineering by: jantill. jantill assigned to issue for Support Engineering Group. ---------- Action by: jneedle If Peter wants it, Peter certainly may have it. Assigning to him. peterm assigned to issue for Sustaining Engineering. ---------- Action by: peterm Escalated to Bugzilla
This issue was fixed during the EAL3 certification process, it is fixed in U4.
A fix for this problem was committed to the RHEL3 U3 patch pool on 25-Jun-2005 (in kernel version 2.4.21-15.18.EL).
This problem was fixed in U3 (advisory RHBA-2004:433-17), although obviously the latest released kernel should be used (which is 2.4.21-32.0.1.EL, advisory RHSA-2005:472).