Re: [patch 058/209] audit: rework execve audit

[Steve Grubb <sgrubb@redhat.com>]

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@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