Re: [patch 058/209] audit: rework execve audit
On Friday 27 July 2007 16:44:05 Peter Zijlstra wrote:
On Fri, 2007-07-27 at 16:13 -0400, Steve Grubb wrote:
> I was testing our rawhide kernel and I'm scrolling these errors:
How can I reproduce this? (I once figured out how to enable execve
auditing but have since forgotten)
I don't know of anything special its a fully updated rawhide machine. I am not
running any tests, this is at the prompt in runlevel 3. I have audit=1 as a
boot parameter in grub.conf and very simple audit rules for that machine:
-D
-b 256
-a exit,always -S sethostname
-w /etc/selinux/config
which is not exotic.
And are you doing more than enabling it?
Not really.
That is, does it auto-magically happen,
correct...while sitting at the prompt.
> WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not
tainted)
>
> Call Trace:
> [<ffffffff8106b06f>] audit_log_exit+0x5d7/0x964
> [<ffffffff81050805>] trace_hardirqs_on+0x12e/0x151
> [<ffffffff8106b60b>] audit_syscall_exit+0x9b/0x300
> [<ffffffff8100ee62>] syscall_trace_leave+0x2c/0x87
> [<ffffffff8100beb1>] int_very_careful+0x3a/0x43
>
> > From: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
> > diff -puN kernel/auditsc.c~audit-rework-execve-audit kernel/auditsc.c
> > --- a/kernel/auditsc.c~audit-rework-execve-audit
> > +++ a/kernel/auditsc.c
> > @@ -831,6 +831,55 @@ static int audit_log_pid_context(struct
> > return rc;
> > }
> >
> > +static void audit_log_execve_info(struct audit_buffer *ab,
> > + struct audit_aux_data_execve *axi)
> > +{
> > + int i;
> > + long len, ret;
> > + const char __user *p = (const char __user *)axi->mm->arg_start;
> > + char *buf;
> > +
> > + if (axi->mm != current->mm)
> > + return; /* execve failed, no additional info */
> > +
> > + for (i = 0; i < axi->argc; i++, p += len) {
> > + len = strnlen_user(p, MAX_ARG_PAGES*PAGE_SIZE);
> > + /*
> > + * We just created this mm, if we can't find the strings
> > + * we just copied into it something is _very_ wrong. Similar
> > + * for strings that are too long, we should not have created
> > + * any.
> > + */
> > + if (!len || len > MAX_ARG_STRLEN) {
> > + WARN_ON(1);
> > + send_sig(SIGKILL, current, 0);
> > + }
>
> Which is right here ^^^
>
> Any ideas?
Not from the top of my head, like the comment suggests, its not supposed
to happen :-(. It would be interesting to know if i == 0, if so that
would suggest arg_start is fuzzed, if not something else has gone south.
Is that all you want is i's value? maybe len too? The trace was awfully short.
Is there a way to make it tell more about what was in the call chain? IOW,
tracing back to sys_execve entry.
-Steve