Re: [GIT PULL] audit patches

[Stephen Smalley]

On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
> On Sun, 18 Feb 2007 04:01:27 +0000 Al Viro <viro@xxxxxxxxxxxxxxxx> wrote:
> 
> > Misc audit patches (resend again...); the most intrusive one is AUDIT_FD_PAIR,
> > allowing to log descriptor numbers from syscalls that do not return them in
> > usual way (i.e. pipe() and socketpair()).  It took some massage of
> > the failure exits in sys_socketpair(); the rest is absolutely trivial.
> > Please, pull from
> > git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/ audit.b37
> 
> Please send patches to the list for review if practical?  In this case it
> was.  I trust davem has had a look at the non-trivial changes to
> sys_socketpair().
> 
> 
> 
> Looking at the changes to audit_receive_msg():
> 
> 
> 				if (sid) {
> 					if (selinux_sid_to_string(
> 							sid, &ctx, &len)) {
> 						audit_log_format(ab,
> 							" ssid=%u", sid);
> 						/* Maybe call audit_panic? */
> 					} else
> 						audit_log_format(ab,
> 							" subj=%s", ctx);
> 					kfree(ctx);
> 				}
> 
> This is assuming that selinux_sid_to_string() always initialises `ctx'.
> 
> But AFAICT there are two error paths in security_sid_to_context() which
> forget to do that, so we end up doing kfree(uninitialised-local).
> 
> I'd consider that a shortcoming in security_sid_to_context(), so not a
> problem in this patch, as long as people agree with my blaming above.

I wouldn't assume that the function initializes an argument if it
returns an error, and at least some of the callers (in auditsc.c) appear
to correctly initialize ctx to NULL themselves before calling
selinux_sid_to_string().  But if you'd prefer the function to always
handle it, we can do that.

> 
> The coding style in there is a bit odd-looking.
> 
> The new __audit_fd_pair() has unneeded braces in it.
-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/