<div dir="ltr">So we must drop the "reason" field for abnormal end due to signal delivery. <div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 9:23 PM, Eric Paris <span dir="ltr"><<a href="mailto:eparis@redhat.com" target="_blank">eparis@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 2013-11-07 at 21:21 +0530, Paul Davies C wrote:<br>
> So rather than logging the "reason=memory violation" when process ends<br>
> abnormally due to any signal delivery , it will be be better if we<br>
> leave "reason=undefined" .<br>
<br>
</div>reason=memory_violation or invalid_pointer etc<br>
<br>
although maybe it should be just 'signal'... and you can get the signal<br>
number from the record....<br>
<div class="HOEnZb"><div class="h5"><br>
> Your thoughts?<br>
><br>
><br>
> On Thu, Nov 7, 2013 at 9:12 PM, Eric Paris <<a href="mailto:eparis@redhat.com">eparis@redhat.com</a>> wrote:<br>
> On Thu, 2013-11-07 at 10:05 -0500, Steve Grubb wrote:<br>
> > On Thursday, November 07, 2013 09:43:24 AM Eric Paris wrote:<br>
> > > On Thu, 2013-11-07 at 19:09 +0530, Paul Davies C wrote:<br>
> > > > The audit system logs the signals that leads to abnormal<br>
> end of a process.<br>
> > > > However , as of now , it always states the reason for<br>
> failure of a process<br>
> > > > as "memory violation" regardless of the signal<br>
> delivered. This is due to<br>
> > > > the audit_core_dumps() function pass the reason for<br>
> failure blindly to<br>
> > > > the audit_log_abend() as "memory violation".<br>
> > > ><br>
> > > > This patch changes the audit_core_dumps() function as to<br>
> pass on the right<br>
> > > > reason to the audit_log_abend based on the signal<br>
> received.<br>
> > > ><br>
> > > > Signed-off-by:Paul Davies C<br>
> > ><br>
> > > Acked-by: Eric Paris <<a href="mailto:eparis@redhat.com">eparis@redhat.com</a>><br>
> > ><br>
> > > But we really should wait for an Ack and thoughts from<br>
> steve grubb....<br>
> ><br>
> > I am confused. This is the abnormal end event I have:<br>
> ><br>
> > type=ANOM_ABEND msg=audit(1303339663.307:142): auid=4325<br>
> uid=0 gid=0 ses=1<br>
> > subj=unconfined_u:unconfined_r:unconfined_t:s0 pid=3775<br>
> comm="aureport" sig=11<br>
> ><br>
> > Why / when did we start adding text explanations? We should<br>
> not do that. We<br>
> > didn't have it before and it should not have been added. The<br>
> signal number is<br>
> > enough to identify the problem.<br>
><br>
><br>
> We started adding a reason when seccomp started sending<br>
> ANOM_ABEND<br>
> events as well. It doesn't do so with a signal. Agreed, the<br>
> " " is/was<br>
> a bad idea...<br>
><br>
> ><br>
> > If we did need a reason= field, all these strings with<br>
> spaces will get<br>
> > separated on parsing. They should be like "memory-violation"<br>
> or "recieved-<br>
> > abort". And would it be better to hide this in the<br>
> audit_log_abend function? I<br>
> > honestly don't understand why this was added.<br>
> ><br>
> > -Steve<br>
> ><br>
> ><br>
> > > > ---<br>
> > > ><br>
> > > > kernel/auditsc.c | 31 ++++++++++++++++++++++++++++++-<br>
> > > > 1 file changed, 30 insertions(+), 1 deletion(-)<br>
> > > ><br>
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c<br>
> > > > index 9845cb3..3cafd13 100644<br>
> > > > --- a/kernel/auditsc.c<br>
> > > > +++ b/kernel/auditsc.c<br>
> > > > @@ -2395,7 +2395,36 @@ void audit_core_dumps(long signr)<br>
> > > ><br>
> > > > ab = audit_log_start(NULL, GFP_KERNEL,<br>
> AUDIT_ANOM_ABEND);<br>
> > > > if (unlikely(!ab))<br>
> > > ><br>
> > > > return;<br>
> > > ><br>
> > > > - audit_log_abend(ab, "memory violation", signr);<br>
> > > > +<br>
> > > > + /*Identify the reason for failure based on signal<br>
> delivered.*/<br>
> > > > + switch (signr) {<br>
> > > > + case SIGABRT:<br>
> > > > + audit_log_abend(ab, "received abort",<br>
> signr);<br>
> > > > + break;<br>
> > > > + case SIGBUS:<br>
> > > > + audit_log_abend(ab, "invalid pointer<br>
> dereference", signr);<br>
> > > > + break;<br>
> > > > + case SIGFPE:<br>
> > > > + audit_log_abend(ab, "invalid floating<br>
> point instruction",<br>
> > signr);<br>
> > > > + break;<br>
> > > > + case SIGILL:<br>
> > > > + audit_log_abend(ab, "illegal<br>
> instruction", signr);<br>
> > > > + break;<br>
> > > > + case SIGSEGV:<br>
> > > > + audit_log_abend(ab, "memory<br>
> violation", signr);<br>
> > > > + break;<br>
> > > > + case SIGTRAP:<br>
> > > > + audit_log_abend(ab, "bad instruction /<br>
> debugger generated<br>
> > signal",<br>
> > > > signr); + break;<br>
> > > > + case SIGXCPU:<br>
> > > > + audit_log_abend(ab, "cpu time<br>
> violation", signr);<br>
> > > > + break;<br>
> > > > + case SIGXFSZ:<br>
> > > > + audit_log_abend(ab, "file size<br>
> violation", signr);<br>
> > > > + break;<br>
> > > > + default:<br>
> > > > + audit_log_abend(ab, "not defined",<br>
> signr);<br>
> > > > + }<br>
> > > ><br>
> > > > audit_log_end(ab);<br>
> > > ><br>
> > > > }<br>
> ><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Paul Davies C<br>
> <a href="http://vivafoss.blogspot.com" target="_blank">vivafoss.blogspot.com</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><font face="'arial narrow', sans-serif" color="#C0C0C0"><b>Regards,</b></font></div><div><font face="'arial narrow', sans-serif" color="#C0C0C0"><b>Paul Davies C</b></font></div>
<a href="http://vivafoss.blogspot.com" target="_blank">vivafoss.blogspot.com</a>
</div></div>