All of lore.kernel.org
 help / color / mirror / Atom feed
* How to monitor audit/audispd killed
@ 2016-01-04 12:10 Matthew Chao
  2016-01-04 14:12 ` Richard Guy Briggs
  2016-01-04 14:32 ` Steve Grubb
  0 siblings, 2 replies; 11+ messages in thread
From: Matthew Chao @ 2016-01-04 12:10 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 519 bytes --]

Hi,

I added the following rules in audit.rules for monitoring auditd/audispd be
killed(audit ver: 1.8),
=============
-a exit,always -F perm=wa -F path=/var/run/auditd.pid -k cfg

-a exit,always -F perm=wa -F path=/var/run/audispd_events -k cfg

Or
-a exit,always -S kill -F path=/var/run/auditd.pid -k cfg

-a exit,always -S kill -F path=/var/run/audispd_events -k cfg
=============

However, these rules don't work: even the processes (auditd/audispd) are
killed, I can't get any related messages except DAEMON_END.

[-- Attachment #1.2: Type: text/html, Size: 726 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 12:10 How to monitor audit/audispd killed Matthew Chao
@ 2016-01-04 14:12 ` Richard Guy Briggs
  2016-01-04 19:49   ` Matthew Chao
  2016-01-04 14:32 ` Steve Grubb
  1 sibling, 1 reply; 11+ messages in thread
From: Richard Guy Briggs @ 2016-01-04 14:12 UTC (permalink / raw)
  To: Matthew Chao; +Cc: linux-audit

On 16/01/04, Matthew Chao wrote:
> Hi,
> 
> I added the following rules in audit.rules for monitoring auditd/audispd be
> killed(audit ver: 1.8),
> =============
> -a exit,always -F perm=wa -F path=/var/run/auditd.pid -k cfg
> 
> -a exit,always -F perm=wa -F path=/var/run/audispd_events -k cfg
> 
> Or
> -a exit,always -S kill -F path=/var/run/auditd.pid -k cfg
> 
> -a exit,always -S kill -F path=/var/run/audispd_events -k cfg
> =============
> 
> However, these rules don't work: even the processes (auditd/audispd) are
> killed, I can't get any related messages except DAEMON_END.

Is that because auditd is no longer there to receive that message?  Did
it show up in syslog or were you able to re-start auditd before the hold
queue overflowed to be able to pick up those messages?


- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 12:10 How to monitor audit/audispd killed Matthew Chao
  2016-01-04 14:12 ` Richard Guy Briggs
@ 2016-01-04 14:32 ` Steve Grubb
  2016-01-04 19:29   ` Matthew Chao
  1 sibling, 1 reply; 11+ messages in thread
From: Steve Grubb @ 2016-01-04 14:32 UTC (permalink / raw)
  To: linux-audit

On Monday, January 04, 2016 08:10:29 PM Matthew Chao wrote:
> Hi,
> 
> I added the following rules in audit.rules for monitoring auditd/audispd be
> killed(audit ver: 1.8),
> =============
> -a exit,always -F perm=wa -F path=/var/run/auditd.pid -k cfg
> 
> -a exit,always -F perm=wa -F path=/var/run/audispd_events -k cfg
> 
> Or
> -a exit,always -S kill -F path=/var/run/auditd.pid -k cfg
> 
> -a exit,always -S kill -F path=/var/run/audispd_events -k cfg
> =============
> 
> However, these rules don't work:

You have a race condition where auditd gets a signal to shutdown and an event 
indicating that shutdown is occurring. On shutdown, the audit daemon does not 
alter the rules or whether auditing is enabled. (This was to get shutdown AVCs 
for selinux.) There is a chance that your event is in syslog's files.


> even the processes (auditd/audispd) are killed, I can't get any related
> messages except DAEMON_END.

The daemon end event should give you 2 things, who issued the shutdown (auid) 
and the sending pid. That should let you track it down.

-Steve

^ permalink raw reply	[flat|nested] 11+ messages in thread

* How to monitor audit/audispd killed
  2016-01-04 14:32 ` Steve Grubb
@ 2016-01-04 19:29   ` Matthew Chao
  2016-01-04 19:43     ` Steve Grubb
  0 siblings, 1 reply; 11+ messages in thread
From: Matthew Chao @ 2016-01-04 19:29 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 510 bytes --]

>You have a race condition where auditd gets a signal to shutdown and an
event
>indicating that shutdown is occurring. On shutdown, the audit daemon does
not
>alter the rules or whether auditing is enabled. (This was to get shutdown
AVCs
>for selinux.) There is a chance that your event is in syslog's files.


For clarity, I am still not sure whether audit rules can be written to
monitor auditd/auispd killed or not (syslog was disabled under my
circumstances ).
If yes, could you give me some tips? Thanks.

[-- Attachment #1.2: Type: text/html, Size: 609 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 19:29   ` Matthew Chao
@ 2016-01-04 19:43     ` Steve Grubb
  2016-01-04 19:51       ` Matthew Chao
  2016-01-05 10:08       ` Matthew Chao
  0 siblings, 2 replies; 11+ messages in thread
From: Steve Grubb @ 2016-01-04 19:43 UTC (permalink / raw)
  To: Matthew Chao; +Cc: linux-audit

On Tuesday, January 05, 2016 03:29:31 AM Matthew Chao wrote:
> >You have a race condition where auditd gets a signal to shutdown and an
> event indicating that shutdown is occurring. On shutdown, the audit daemon
> does not alter the rules or whether auditing is enabled. (This was to get
> shutdown AVCs for selinux.) There is a chance that your event is in syslog's
> files.
> 
> For clarity, I am still not sure whether audit rules can be written to
> monitor auditd/auispd killed or not (syslog was disabled under my
> circumstances ).

You cannot audit the audit daemon's pid. Otherwise servicing an event could 
create several more events which cause even more and you get an exponential 
increase in logging until it dies.

You can watch audispd, but I don't think that will help anything.


> If yes, could you give me some tips? Thanks.

The audit daemon is required to log some information about why it shutdown. If 
you have a daemon_end event, this is the required information. Is there 
something not in the event that you need?

-Steve

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 14:12 ` Richard Guy Briggs
@ 2016-01-04 19:49   ` Matthew Chao
  0 siblings, 0 replies; 11+ messages in thread
From: Matthew Chao @ 2016-01-04 19:49 UTC (permalink / raw)
  To: Richard Guy Briggs; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 1357 bytes --]

my syslogd was disabled.
Also, after auditd restarting, those messages don't appear anymore.

I want to know if auditd ( and its child process: audispd) can monitor
themselves killed or not.


On Monday, January 4, 2016, Richard Guy Briggs <rgb@redhat.com> wrote:

> On 16/01/04, Matthew Chao wrote:
> > Hi,
> >
> > I added the following rules in audit.rules for monitoring auditd/audispd
> be
> > killed(audit ver: 1.8),
> > =============
> > -a exit,always -F perm=wa -F path=/var/run/auditd.pid -k cfg
> >
> > -a exit,always -F perm=wa -F path=/var/run/audispd_events -k cfg
> >
> > Or
> > -a exit,always -S kill -F path=/var/run/auditd.pid -k cfg
> >
> > -a exit,always -S kill -F path=/var/run/audispd_events -k cfg
> > =============
> >
> > However, these rules don't work: even the processes (auditd/audispd) are
> > killed, I can't get any related messages except DAEMON_END.
>
> Is that because auditd is no longer there to receive that message?  Did
> it show up in syslog or were you able to re-start auditd before the hold
> queue overflowed to be able to pick up those messages?
>
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>

[-- Attachment #1.2: Type: text/html, Size: 1810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 19:43     ` Steve Grubb
@ 2016-01-04 19:51       ` Matthew Chao
  2016-01-05 10:08       ` Matthew Chao
  1 sibling, 0 replies; 11+ messages in thread
From: Matthew Chao @ 2016-01-04 19:51 UTC (permalink / raw)
  To: Richard Guy Briggs; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 1357 bytes --]

my syslogd was disabled.
Also, after auditd restarting, those messages don't appear anymore.

I want to know if auditd ( and its child process: audispd) can monitor
themselves killed or not.


On Monday, January 4, 2016, Richard Guy Briggs <rgb@redhat.com> wrote:

> On 16/01/04, Matthew Chao wrote:
> > Hi,
> >
> > I added the following rules in audit.rules for monitoring auditd/audispd
> be
> > killed(audit ver: 1.8),
> > =============
> > -a exit,always -F perm=wa -F path=/var/run/auditd.pid -k cfg
> >
> > -a exit,always -F perm=wa -F path=/var/run/audispd_events -k cfg
> >
> > Or
> > -a exit,always -S kill -F path=/var/run/auditd.pid -k cfg
> >
> > -a exit,always -S kill -F path=/var/run/audispd_events -k cfg
> > =============
> >
> > However, these rules don't work: even the processes (auditd/audispd) are
> > killed, I can't get any related messages except DAEMON_END.
>
> Is that because auditd is no longer there to receive that message?  Did
> it show up in syslog or were you able to re-start auditd before the hold
> queue overflowed to be able to pick up those messages?
>
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>

[-- Attachment #1.2: Type: text/html, Size: 1810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-04 19:43     ` Steve Grubb
  2016-01-04 19:51       ` Matthew Chao
@ 2016-01-05 10:08       ` Matthew Chao
  2016-01-05 14:10         ` Steve Grubb
  1 sibling, 1 reply; 11+ messages in thread
From: Matthew Chao @ 2016-01-05 10:08 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 405 bytes --]

>"You can watch audispd, but I don't think that will help anything.

my program totally depends on audispd to dispatch audit messages. I think
audispd need more robust mechanisms to monitor itself killed, otherwise
which inevitably leads to that audispd' plugins receive nothing but always
wait wait wait for event messages.

So are there some alternative ways to monitor audispd killed in audit
ver1.8 ?

[-- Attachment #1.2: Type: text/html, Size: 493 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-05 10:08       ` Matthew Chao
@ 2016-01-05 14:10         ` Steve Grubb
  2016-01-05 16:12           ` Matthew Chao
  0 siblings, 1 reply; 11+ messages in thread
From: Steve Grubb @ 2016-01-05 14:10 UTC (permalink / raw)
  To: Matthew Chao; +Cc: linux-audit

On Tuesday, January 05, 2016 06:08:54 PM Matthew Chao wrote:
> >"You can watch audispd, but I don't think that will help anything.
> 
> my program totally depends on audispd to dispatch audit messages. I think
> audispd need more robust mechanisms to monitor itself killed, otherwise
> which inevitably leads to that audispd' plugins receive nothing but always
> wait wait wait for event messages.
> 
> So are there some alternative ways to monitor audispd killed in audit
> ver1.8 ?

To help you, I need to know more about what the actual problem is that you are 
trying to solve. Would you like to explain the problem so we can help figure 
out how to address it?

Thanks,
-Steve

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-05 14:10         ` Steve Grubb
@ 2016-01-05 16:12           ` Matthew Chao
  2016-01-05 17:48             ` Steve Grubb
  0 siblings, 1 reply; 11+ messages in thread
From: Matthew Chao @ 2016-01-05 16:12 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 990 bytes --]

In short, my question is: my program depends on audispd to dispatch audit
messages, for security's sake, when audispd is killed, how can I know it
happened in time in order to restart audispd?

Thanks.

On Tuesday, January 5, 2016, Steve Grubb <sgrubb@redhat.com> wrote:

> On Tuesday, January 05, 2016 06:08:54 PM Matthew Chao wrote:
> > >"You can watch audispd, but I don't think that will help anything.
> >
> > my program totally depends on audispd to dispatch audit messages. I think
> > audispd need more robust mechanisms to monitor itself killed, otherwise
> > which inevitably leads to that audispd' plugins receive nothing but
> always
> > wait wait wait for event messages.
> >
> > So are there some alternative ways to monitor audispd killed in audit
> > ver1.8 ?
>
> To help you, I need to know more about what the actual problem is that you
> are
> trying to solve. Would you like to explain the problem so we can help
> figure
> out how to address it?
>
> Thanks,
> -Steve
>

[-- Attachment #1.2: Type: text/html, Size: 1277 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: How to monitor audit/audispd killed
  2016-01-05 16:12           ` Matthew Chao
@ 2016-01-05 17:48             ` Steve Grubb
  0 siblings, 0 replies; 11+ messages in thread
From: Steve Grubb @ 2016-01-05 17:48 UTC (permalink / raw)
  To: Matthew Chao; +Cc: linux-audit

On Wednesday, January 06, 2016 12:12:54 AM Matthew Chao wrote:
> In short, my question is: my program depends on audispd to dispatch audit
> messages, for security's sake, when audispd is killed, how can I know it
> happened in time in order to restart audispd?

I think that you have to approach the problem from a different angle. As a 
child of audispd, you will probably get a SIGPIPE which if unhandled will 
cause termination. That said, your application can't really start audispd 
because auditd needs to in order to setup the pipes. Then audispd needs to 
start your plugin.

But that raises to the question of are you seeing any problems that cause 
audispd to be killed? The reason I ask is that no one is reporting problems 
where either auditd or audispd are terminating due to a fault.

But if you were just wanting to be careful, then you really ought to write a 
small program that its whole job is to start auditd and catch SIGCHLD. When 
you catch SIGCHLD, restart the audit daemon. If your watcher gets any signals 
such as SIGHUP/USR1/USR2/TERM, then pass them along to auditd.

If you are on a system with systemd as the init system, it already has a 
Restart= option to restart a critical service if it shutsdown. That said, an 
admin can always shutdown the audit service if they want to.

Are you having problems with audispd or just trying to be careful with a 
design?

Hope this helps...

-Steve


> On Tuesday, January 5, 2016, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, January 05, 2016 06:08:54 PM Matthew Chao wrote:
> > > >"You can watch audispd, but I don't think that will help anything.
> > > 
> > > my program totally depends on audispd to dispatch audit messages. I
> > > think
> > > audispd need more robust mechanisms to monitor itself killed, otherwise
> > > which inevitably leads to that audispd' plugins receive nothing but
> > 
> > always
> > 
> > > wait wait wait for event messages.
> > > 
> > > So are there some alternative ways to monitor audispd killed in audit
> > > ver1.8 ?
> > 
> > To help you, I need to know more about what the actual problem is that you
> > are
> > trying to solve. Would you like to explain the problem so we can help
> > figure
> > out how to address it?
> > 
> > Thanks,
> > -Steve

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-01-05 17:48 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-04 12:10 How to monitor audit/audispd killed Matthew Chao
2016-01-04 14:12 ` Richard Guy Briggs
2016-01-04 19:49   ` Matthew Chao
2016-01-04 14:32 ` Steve Grubb
2016-01-04 19:29   ` Matthew Chao
2016-01-04 19:43     ` Steve Grubb
2016-01-04 19:51       ` Matthew Chao
2016-01-05 10:08       ` Matthew Chao
2016-01-05 14:10         ` Steve Grubb
2016-01-05 16:12           ` Matthew Chao
2016-01-05 17:48             ` Steve Grubb

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.