* auditd restart atomic? @ 2017-02-07 1:12 Chris Nandor 2017-02-07 15:05 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Chris Nandor @ 2017-02-07 1:12 UTC (permalink / raw) To: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 180 bytes --] If I restart auditd, can it lose (not record to the logs) events that happen during the restart? Or is the restart (and reload of new rules) essentially atomic? Thanks, --Chris [-- Attachment #1.2: Type: text/html, Size: 266 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: auditd restart atomic? 2017-02-07 1:12 auditd restart atomic? Chris Nandor @ 2017-02-07 15:05 ` Paul Moore 2017-02-07 15:26 ` Richard Guy Briggs 0 siblings, 1 reply; 4+ messages in thread From: Paul Moore @ 2017-02-07 15:05 UTC (permalink / raw) To: Chris Nandor; +Cc: linux-audit On Mon, Feb 6, 2017 at 8:12 PM, Chris Nandor <pudge@pobox.com> wrote: > If I restart auditd, can it lose (not record to the logs) events that happen > during the restart? Or is the restart (and reload of new rules) essentially > atomic? The kernel maintains a backlog queue of audit records when auditd is not running and attempts to (re)send those records when auditd is started. However, the backlog queue size is fixed and it is possible to overflow the queue; if that happens a message will be sent to the kernel's ring buffer (dmesg). -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: auditd restart atomic? 2017-02-07 15:05 ` Paul Moore @ 2017-02-07 15:26 ` Richard Guy Briggs 2017-02-07 20:58 ` Chris Nandor 0 siblings, 1 reply; 4+ messages in thread From: Richard Guy Briggs @ 2017-02-07 15:26 UTC (permalink / raw) To: Paul Moore; +Cc: linux-audit On 2017-02-07 10:05, Paul Moore wrote: > On Mon, Feb 6, 2017 at 8:12 PM, Chris Nandor <pudge@pobox.com> wrote: > > If I restart auditd, can it lose (not record to the logs) events that happen > > during the restart? Or is the restart (and reload of new rules) essentially > > atomic? > > The kernel maintains a backlog queue of audit records when auditd is > not running and attempts to (re)send those records when auditd is > started. However, the backlog queue size is fixed and it is possible > to overflow the queue; if that happens a message will be sent to the > kernel's ring buffer (dmesg). The default is 64, the value recommended in some documentation is 320, but values of 8k (8192) have been recommended to have enough buffer for events like an auditd restart. Chris, to answer the other half of your question, with respect to rules being reloaded atomically, it isn't. My understanding is it starts with a -D to clear out all the rules and then adds rules in sequence from the /etc/audit/audit.rules file, so it would be possible to miss an event because the rule did not re-exist yet, unless you set your last rule to -e 2 to make the ruleset immutable, in which case the restart of auditd will have no effect on the existing immutable rule set. > paul moore - RGB -- Richard Guy Briggs <rgb@redhat.com> Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: auditd restart atomic? 2017-02-07 15:26 ` Richard Guy Briggs @ 2017-02-07 20:58 ` Chris Nandor 0 siblings, 0 replies; 4+ messages in thread From: Chris Nandor @ 2017-02-07 20:58 UTC (permalink / raw) To: Richard Guy Briggs; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 2025 bytes --] Great, thanks Paul and Richard for the input (and we do have an 8192 backlog queue). We won't be doing immutable rules, but we'll document that when we change our chef recipes that update the config, that this will have the effect of deleting rules, so some events may not be logged. We have talked about using -e 2, but we're still working through our rules ... when we finalize them, we may go to that. Thanks, --Chris On Tue, Feb 7, 2017 at 7:26 AM, Richard Guy Briggs <rgb@redhat.com> wrote: > On 2017-02-07 10:05, Paul Moore wrote: > > On Mon, Feb 6, 2017 at 8:12 PM, Chris Nandor <pudge@pobox.com> wrote: > > > If I restart auditd, can it lose (not record to the logs) events that > happen > > > during the restart? Or is the restart (and reload of new rules) > essentially > > > atomic? > > > > The kernel maintains a backlog queue of audit records when auditd is > > not running and attempts to (re)send those records when auditd is > > started. However, the backlog queue size is fixed and it is possible > > to overflow the queue; if that happens a message will be sent to the > > kernel's ring buffer (dmesg). > > The default is 64, the value recommended in some documentation is 320, > but values of 8k (8192) have been recommended to have enough buffer for > events like an auditd restart. > > Chris, to answer the other half of your question, with respect to rules > being reloaded atomically, it isn't. My understanding is it starts with > a -D to clear out all the rules and then adds rules in sequence from the > /etc/audit/audit.rules file, so it would be possible to miss an event > because the rule did not re-exist yet, unless you set your last rule to > -e 2 to make the ruleset immutable, in which case the restart of auditd > will have no effect on the existing immutable rule set. > > > paul moore > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Kernel Security Engineering, Base Operating Systems, Red Hat > Remote, Ottawa, Canada > Voice: +1.647.777.2635, Internal: (81) 32635 > [-- Attachment #1.2: Type: text/html, Size: 2728 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-02-07 20:58 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-07 1:12 auditd restart atomic? Chris Nandor 2017-02-07 15:05 ` Paul Moore 2017-02-07 15:26 ` Richard Guy Briggs 2017-02-07 20:58 ` Chris Nandor
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.