Re: Audit not recording the correct syscall return value in Fedora 10?

[Tony Jones <tonyj@suse.de>]

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