Re: Audit not recording the correct syscall return value in Fedora 10?
On Tue, Apr 07, 2009 at 11:44:09PM -0300, Klaus Heinrich Kiwi wrote:
On Tue, 2009-04-07 at 11:34 -0400, Paul Moore wrote:
> Does anyone have any thoughts?
I remember debugging an issue with the incorrect return value being
audited for a syscall. It was s390[x] specific and only occurred with
successful execve() syscalls. This behavior was pointed out with the
open-source common-criteria testsuite that checked each
security-relevant syscalls for parameters, return values, args etc..
I didn't give much important to those since execve() return value is
really not that important if the call succeeds ;-)
But now I'm curious to what other problems related to syscalls return
values you've found, and how those weren't caught by the same set of
tests (hmm, maybe they are x86-specific?)
Can you give us some examples?
Klaus. I need to kick this bug upstream. I'll do so today. I thought I'd
tracked it down to some specific execve code in the entry sequence, that was a
while ago, I got back to looking at it and I can't find that code anymore :-(
but it still fails.
For S390[x] you'll get audit events of the form:
type=SYSCALL msg=audit(1179421699.058:39809): arch=80000016 syscall=11
success=yes exit=11 a0=3ffff91ce50 a1=3ffff91e240 a2=3ffff91e250 a3=20000162a58
items=2 ppid=13131 pid=13132 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 comm="true" exe="/bin/true"
subj=unconstrained
key=(null)
strace shows that the syscall succeeded.
My S390 assembler knowledge is non-existant but appears that the syscall value
is somehow in gprs[2] rather than the return value when the codepath enters
s390/kernel/ptrace.c::do_syscall_trace_exit. Only for the execve syscall.
Tony