6:10 a.m.
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.
8:12 a.m.
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(a)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
1:49 p.m.
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(a)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(a)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
8:32 a.m.
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
1:29 p.m.
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.
1:43 p.m.
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
1:51 p.m.
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(a)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(a)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
4:08 a.m.
"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 ?
8:10 a.m.
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
10:12 a.m.
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(a)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
11:48 a.m.
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(a)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
3274
days inactive
3275
days old
linux-audit@lists.linux-audit.osci.io
10 comments
3 participants
participants (3)
-
Matthew Chao -
Richard Guy Briggs -
Steve Grubb