* SIGXCPU and Auditd
@ 2013-11-05 13:09 Paul Davies C
2013-11-05 13:27 ` Steve Grubb
0 siblings, 1 reply; 5+ messages in thread
From: Paul Davies C @ 2013-11-05 13:09 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 329 bytes --]
Hi,
Is there any way to make the *auditd system to log the SIGXCPU signal*?
As of now , without writing any specific rules, SIGSEGV is getting
logged. In my log I found lines as below :
/
type=ANOM_ABEND msg=audit(1383644379.989:88): auid=1000 uid=1000
gid=1000 ses=5 pid=2688 comm="chrome" reason="memory violation" sig=11/
[-- Attachment #1.2: Type: text/html, Size: 582 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGXCPU and Auditd
2013-11-05 13:09 SIGXCPU and Auditd Paul Davies C
@ 2013-11-05 13:27 ` Steve Grubb
2013-11-05 13:46 ` Paul Davies C
0 siblings, 1 reply; 5+ messages in thread
From: Steve Grubb @ 2013-11-05 13:27 UTC (permalink / raw)
To: linux-audit
On Tuesday, November 05, 2013 06:39:04 PM Paul Davies C wrote:
> Hi,
>
> Is there any way to make the *auditd system to log the SIGXCPU signal*?
> As of now , without writing any specific rules, SIGSEGV is getting
> logged. In my log I found lines as below :
> /
> type=ANOM_ABEND msg=audit(1383644379.989:88): auid=1000 uid=1000
> gid=1000 ses=5 pid=2688 comm="chrome" reason="memory violation" sig=11/
The ABnormal END event is triggered by any event that would be terminated by
the kernel with a core dump. Looking at the signal(7) man page, SIGXCPU by
default would core. So, it should trigger an event. I don't have a test case
to prove it, though.
Steve
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGXCPU and Auditd
2013-11-05 13:27 ` Steve Grubb
@ 2013-11-05 13:46 ` Paul Davies C
2013-11-05 14:02 ` Steve Grubb
0 siblings, 1 reply; 5+ messages in thread
From: Paul Davies C @ 2013-11-05 13:46 UTC (permalink / raw)
To: Steve Grubb, linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 122 bytes --]
In the man page it is written that *core dump on SIGXCPU **can fail* .
That is probably the reason why it is not logged.
[-- Attachment #1.2: Type: text/html, Size: 314 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGXCPU and Auditd
2013-11-05 13:46 ` Paul Davies C
@ 2013-11-05 14:02 ` Steve Grubb
2013-11-11 10:54 ` Paul Davies C
0 siblings, 1 reply; 5+ messages in thread
From: Steve Grubb @ 2013-11-05 14:02 UTC (permalink / raw)
To: Paul Davies C; +Cc: linux-audit
On Tuesday, November 05, 2013 07:16:21 PM Paul Davies C wrote:
> In the man page it is written that *core dump on SIGXCPU **can fail* .
> That is probably the reason why it is not logged.
I think we would want the event even if the core dump failed. Maybe the hook
placement needs review? Its probably been 5 years since it was put in the
kernel...that's a lot of time for things to change.
-Steve
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGXCPU and Auditd
2013-11-05 14:02 ` Steve Grubb
@ 2013-11-11 10:54 ` Paul Davies C
0 siblings, 0 replies; 5+ messages in thread
From: Paul Davies C @ 2013-11-11 10:54 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
Audit system do logs the core dump signals. It was a misunderstanding
from my part that lead me to believe that audit does not log SIGXCPU.
Sorry for the confusion.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-11-11 10:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-05 13:09 SIGXCPU and Auditd Paul Davies C
2013-11-05 13:27 ` Steve Grubb
2013-11-05 13:46 ` Paul Davies C
2013-11-05 14:02 ` Steve Grubb
2013-11-11 10:54 ` Paul Davies C
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox