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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
