6:57 p.m.
Hi David,
Which kernel version on
ftp://ftp.uk.linux.org/pub/people/dwmw2/audit/kernel/
is the first to include the hooks you inserted to correctly log the
arguments of the ipc syscalls?
Thanks,
debbie
8:51 a.m.
New subject: audit syscall information
On Wed, 2005-04-27 at 18:57 -0500, Debora Velarde wrote:
<html><body><p>Hi David,<br><br>Which
kernel version on <a
href="ftp://ftp.uk.linux.org/pub/people/dwmw2/audit/kernel/">...
is the first to include the hooks you inserted to correctly log the
arguments of the ipc
syscalls?<br><br>Thanks,<br>debbie</body></html>
Please don't send HTML mail.
The information you request is in the changelog of the kernel RPM:
$ rpm -q --changelog kernel | grep -B1 IPC
- * Fri Feb 18 2005 David Woodhouse <dwmw2(a)redhat.com> audit.6
- Fix list handling errors in IPC patch
--
- * Tue Feb 1 2005 David Woodhouse <dwmw2(a)redhat.com> audit.4
- Log requested values of IPC_SET calls.
--
--
dwmw2
10:32 a.m.
New subject: audit syscall information
The information you request is in the changelog of the kernel RPM:
$ rpm -q --changelog kernel | grep -B1 IPC
- * Fri Feb 18 2005 David Woodhouse <dwmw2(a)redhat.com> audit.6
- Fix list handling errors in IPC patch
--
- * Tue Feb 1 2005 David Woodhouse <dwmw2(a)redhat.com> audit.4
- Log requested values of IPC_SET calls.
--
Then this patch is already on the system I am testing on.
But the a0, a1, a2, and a3 values for the IPC syscalls are still not
matching the expected values when compiled and run in 32bit mode on a 64bit
system.
This is particularly important for the ipc syscalls because a0 is used to
indicate a particular IPC syscall.
For example: when semget is executed in 32bit mode on a 64bit system,
instead of a0=2 (value for SEMGET in ipc.h), I am seeing a0=0.
Not only is the record incorrect, but I am also not able to audit only a
particular ipc syscall in 32bit mode.
If I want to only audit semget 32bit syscalls, I should be able to do this
with:
auditctl -a entry,always -F arch=b32 -S ipc -F a0=2
But this doesn't generate any audit records. The only way I can capture
them is by using:
auditctl -a entry,always -F arch=b32 -S ipc
This audits ALL 32bit ipc syscalls
Note, "auditctl -a entry,always -F arch=b64 -S ipc -F a0=2" does have
correct behavior.
-debbie
1:41 p.m.
New subject: audit syscall information
On Fri, 2005-04-29 at 10:32 -0500, Debora Velarde wrote:
Then this patch is already on the system I am testing on.
But the a0, a1, a2, and a3 values for the IPC syscalls are still not
matching the expected values when compiled and run in 32bit mode on a
64bit system.
I think you are misunderstanding the point of the IPC patch. The point
in it was that we wanted to log information which is _not_ directly
available in the syscall arguments (a0, a1, etc.). It isn't relevant to
how we report the contents of those arguments.
Here's what I see when I compile a simple test program for both ppc32
and ppc64 and execute both. The arguments appear correct in both cases,
and you see the 'auxitem' which accompanies the IPC_SET (a2==101) call.
type=KERNEL msg=audit(1114799507.492:3226863): syscall=117 arch=80000015 success=yes
exit=0 a0=17 a1=ffffffffdeadbeef a2=1000 a3=3ff items=0 pid=6551 loginuid=-1 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ipcstuff64"
exe=/home/dwmw2/ipcstuff64
type=KERNEL msg=audit(1114799507.493:3226881): syscall=117 arch=80000015 success=yes
exit=0 a0=18 a1=0 a2=102 a3=0 items=0 pid=6551 loginuid=-1 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 comm="ipcstuff64" exe=/home/dwmw2/ipcstuff64
type=KERNEL msg=audit(1114799507.493:3226898): auxitem=0 qbytes=0 uid=0 gid=4041 mode=1f8
type=KERNEL msg=audit(1114799507.493:3226898): syscall=117 arch=80000015 success=yes
exit=0 a0=18 a1=0 a2=101 a3=0 items=0 pid=6551 loginuid=-1 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 comm="ipcstuff64" exe=/home/dwmw2/ipcstuff64
type=KERNEL msg=audit(1114799518.993:3227560): syscall=117 arch=14 success=yes exit=0
a0=17 a1=deadbeef a2=1000 a3=3ff items=0 pid=6554 loginuid=-1 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 comm="ipcstuff" exe=/home/dwmw2/ipcstuff
type=KERNEL msg=audit(1114799518.994:3227578): syscall=117 arch=14 success=yes exit=0
a0=18 a1=0 a2=102 a3=0 items=0 pid=6554 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="ipcstuff" exe=/home/dwmw2/ipcstuff
type=KERNEL msg=audit(1114799518.994:3227595): auxitem=0 qbytes=0 uid=0 gid=4041 mode=1f8
type=KERNEL msg=audit(1114799518.994:3227595): syscall=117 arch=14 success=yes exit=0
a0=18 a1=0 a2=101 a3=0 items=0 pid=6554 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="ipcstuff" exe=/home/dwmw2/ipcstuff
--
dwmw2
1:52 p.m.
New subject: audit syscall information
On Fri, 2005-04-29 at 19:41 +0100, David Woodhouse wrote:
Here's what I see when I compile a simple test program for both
ppc32
and ppc64 and execute both. The arguments appear correct in both cases,
and you see the 'auxitem' which accompanies the IPC_SET (a2==101) call.
Ah, you're on x86_64, aren't you? The syscall calling convention is
different between i386 and x86_64 calls -- the arguments are actually in
different registers. Try this...
I've abandoned the previous kernel build, which wasn't going to complete
any time soon anyway because there seems to be no S390 in the build farm
today. I'm building with this (and with S390 excluded).
--- linux-2.6.9/arch/x86_64/kernel/ptrace.c~ 2005-04-29 18:28:47.000000000 +0100
+++ linux-2.6.9/arch/x86_64/kernel/ptrace.c 2005-04-29 19:45:41.525874624 +0100
@@ -517,19 +517,26 @@ static void syscall_trace(struct pt_regs
}
}
-#define audit_arch() \
- (test_thread_flag(TIF_IA32) ? AUDIT_ARCH_I386 : AUDIT_ARCH_X86_64)
-
asmlinkage void syscall_trace_enter(struct pt_regs *regs)
{
if (test_thread_flag(TIF_SYSCALL_TRACE)
&& (current->ptrace & PT_PTRACED))
syscall_trace(regs);
- if (unlikely(current->audit_context))
- audit_syscall_entry(current, audit_arch(), regs->orig_rax,
- regs->rdi, regs->rsi,
- regs->rdx, regs->r10);
+ if (unlikely(current->audit_context)) {
+ if (test_thread_flag(TIF_IA32)) {
+ audit_syscall_entry(current, AUDIT_ARCH_I386,
+ regs->orig_rax,
+ regs->rbx, regs->rcx,
+ regs->rdx, regs->rsi);
+
+ } else {
+ audit_syscall_entry(current, AUDIT_ARCH_X86_64,
+ regs->orig_rax,
+ regs->rdi, regs->rsi,
+ regs->rdx, regs->r10);
+ }
+ }
}
--
dwmw2
2:24 p.m.
New subject: audit syscall information
On Fri, 2005-04-29 at 19:41 +0100, David Woodhouse wrote:
> Here's what I see when I compile a simple test program for both ppc32
> and ppc64 and execute both. The arguments appear correct in both cases,
> and you see the 'auxitem' which accompanies the IPC_SET (a2==101) call.
Ah, you're on x86_64, aren't you? The syscall calling
convention is
different between i386 and x86_64 calls -- the arguments are actually in
different registers. Try this...
Yes. I am on x86_64.
I will try this and post the results.
Thanks!
debbie
10:15 a.m.
New subject: audit syscall information
Thanks David. kernel-2.6.9-5.0.3.EL.audit.27 seems to fix the 32bit
syscall parameter problem on X86_64.
Thanks!
debbie
7173
days inactive
7178
days old
linux-audit@lists.linux-audit.osci.io
6 comments
2 participants
participants (2)
-
David Woodhouse -
Debora Velarde