Bug 234077 - LSPP: ppc 32-bit pread not correctly auditing 4th arg (offset)
LSPP: ppc 32-bit pread not correctly auditing 4th arg (offset)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Martin Jenner
re
:
Depends On:
Blocks: 234654
  Show dependency treegraph
 
Reported: 2007-03-26 17:36 EDT by Michael C Thompson
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-03 11:21:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael C Thompson 2007-03-26 17:36:34 EDT
Description of problem:
On ppc64 in 32-bit mode, pread syscall is not audited correctly. The 4th
argument (offset) is consistantly 0.

Version-Release number of selected component (if applicable):
20070208.0

How reproducible:
Always.

Steps to Reproduce:
1. auditctl -a entry,always -F arch=b32 -S pread
2. echo "ABCDEFG" > /tmp/pread_data
3. Compile (gcc -m32) and execute the following:
#include <errno.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main()
{
    int fd;
    char buff[5];

    fd = open("/tmp/pread_data",O_RDONLY);
    pread(fd, buff, 5, 1);
    close(fd);
    return 0;
}
4. See audit record's a3 value.
  
Actual results:
type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=10020b68 a2=5 a3=0 items=0 ppid=12033 pid=14190 auid=502 uid=503
gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2
comm="ranges1_test"
exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test"
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)


Expected results:
type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=10020b68 a2=5 a3=1 items=0 ppid=12033 pid=14190 auid=502 uid=503
gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2
comm="ranges1_test"
exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test"
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)
Comment 1 George C. Wilson 2007-04-02 16:22:40 EDT
Eric: Looks like not an LSPP blocker. WAD. But just how designed.

Problem is passing a 64-bit offset to 32-bit userspace. Broken into regs 4 & 5,
but only audit 4. Reg 4 is high order of offset.
Comment 3 Steve Grubb 2007-04-03 12:23:43 EDT
This should probably be added to LSPP documentation like the other syscalls that
had minor issues. I think we can close this bz.
Comment 4 Eric Paris 2007-04-03 12:28:11 EDT
There is still some discussion going on about if we should special case this
syscall as I'm told was done apparently for networking and ipc.  Thoughts on the
security relevance of pread and pwrite to collect the offset would be of
interest to see if such work would be useful.
Comment 5 Eric Paris 2007-04-03 13:39:50 EDT
Actualy is this working right on ppc64?  When I just built WITHOUT the -m32 and
I have 2 audit rules

[root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b64 -S pread
[root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b32 -S pread

I got

type=SYSCALL msg=audit(1175621755.531:13): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=ffffe8b0 a2=5 a3=0 items=0 pid=2597 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="pread_test" exe="/root/pread_test"

which is most strange to me...
Comment 6 Eric Paris 2007-04-03 13:42:02 EDT
ok, ignore comment #5 for now as it seems the system i'm working isn't even
rhel5 and doesn't even seem to have all the 64 bit libraries installed.   /me
goes to reinstall.
Comment 7 Eric Paris 2007-04-05 15:23:16 EDT
This issue will not be changed for the LSPP kernels as pread/pwrite are not
deemed 'security relevant.'    I'm going to verify my assumptions but for now it
is coming off of the LSPP lists.  I expect this bug to be closed shortly as
"NOTABUG"
Comment 10 RHEL Product and Program Management 2007-05-03 11:21:09 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.