* Failure flag "0" doesn't work @ 2015-08-20 8:09 Alex Beljanski 2015-08-20 9:39 ` Burn Alting 0 siblings, 1 reply; 4+ messages in thread From: Alex Beljanski @ 2015-08-20 8:09 UTC (permalink / raw) To: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 319 bytes --] Hi! We have problem in CentOS 7 with auditd. For our servers we set failure flag 0, but kernel write messages and we see them in dmesg. uname -a Linux 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa | grep audit audit-2.4.1-5.el7.x86_64 Why this doesn't work? [-- Attachment #1.2: Type: text/html, Size: 471 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Failure flag "0" doesn't work 2015-08-20 8:09 Failure flag "0" doesn't work Alex Beljanski @ 2015-08-20 9:39 ` Burn Alting [not found] ` <CAJeTBw8mAYC0RTjuVKC84tEfUVKsB+F_JASkJu4rOQVREV9DOw@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Burn Alting @ 2015-08-20 9:39 UTC (permalink / raw) To: Alex Beljanski; +Cc: linux-audit Alex, Can you provide a little more detail? Perhaps your /etc/audit/auditd.conf, /etc/audit/rules.d/*, your test case, the expected outcome and the outcome you actually get. Regards On Thu, 2015-08-20 at 11:09 +0300, Alex Beljanski wrote: > Hi! > > > We have problem in CentOS 7 with auditd. > > For our servers we set failure flag 0, but kernel write messages and > we see them in dmesg. > > uname -a > Linux 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux > > # rpm -qa | grep audit > audit-2.4.1-5.el7.x86_64 > > > Why this doesn't work? > > > > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAJeTBw8mAYC0RTjuVKC84tEfUVKsB+F_JASkJu4rOQVREV9DOw@mail.gmail.com>]
* Re: Failure flag "0" doesn't work [not found] ` <CAJeTBw8mAYC0RTjuVKC84tEfUVKsB+F_JASkJu4rOQVREV9DOw@mail.gmail.com> @ 2015-08-20 22:15 ` Burn Alting 2015-08-21 0:14 ` Steve Grubb 0 siblings, 1 reply; 4+ messages in thread From: Burn Alting @ 2015-08-20 22:15 UTC (permalink / raw) To: Alex Beljanski; +Cc: linux-audit Alex, This is a little outside my experience. One assumes the audit_failure variable has been set in the kernel (kernel/audit.c). Perhaps you can test this. Given you can get a copy of the kernel source you are running, perhaps trace through what's happening. Using the messages before/during/directly after the death of auditd, and what's routing to dmesg, perhaps you can reverse engineer what is happening. Perhaps someone else on the list can explain why, given -f is set to 0, and the kernel has no user space destination for audit, it still prints (via printk()?) Regards On Thu, 2015-08-20 at 13:17 +0300, Alex Beljanski wrote: > We have custom audit-dispatcher for process events. On some servers > when auditd fails, all audit messages writes to kernel. > We don't want to see all this messages in dmesg and set failure flag > to "0". This doesn't help. > > > # cat /etc/audit/auditd.conf > > log_file = /var/log/audit/audit.log > log_format = NOLOG > log_group = root > priority_boost = 4 > flush = none > num_logs = 1 > disp_qos = lossy > dispatcher = /sbin/audit-dispatcher > name_format = none > max_log_file = 1 > max_log_file_action = keep_logs > space_left = 75 > space_left_action = ignore > admin_space_left = 50 > admin_space_left_action = ignore > disk_full_action = ignore > disk_error_action = ignore > enable_krb5 = no > > cat /etc/audit/rules.d/audit.rules > > -D > > -b 8192 > > -f 0 > -e 1 > > -a exit,always -F arch=b32 -S 11 -k exec32 > -a exit,always -F arch=b64 -S 59 -k exec64 > > > > > 2015-08-20 12:39 GMT+03:00 Burn Alting <burn@swtf.dyndns.org>: > Alex, > > Can you provide a little more detail? > > Perhaps your /etc/audit/auditd.conf, /etc/audit/rules.d/*, > your test > case, the expected outcome and the outcome you actually get. > > Regards > > On Thu, 2015-08-20 at 11:09 +0300, Alex Beljanski wrote: > > Hi! > > > > > > We have problem in CentOS 7 with auditd. > > > > For our servers we set failure flag 0, but kernel write > messages and > > we see them in dmesg. > > > > uname -a > > Linux 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 > UTC 2015 > > x86_64 x86_64 x86_64 GNU/Linux > > > > # rpm -qa | grep audit > > audit-2.4.1-5.el7.x86_64 > > > > > > Why this doesn't work? > > > > > > > > > > > > > -- > > Linux-audit mailing list > > Linux-audit@redhat.com > > https://www.redhat.com/mailman/listinfo/linux-audit > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Failure flag "0" doesn't work 2015-08-20 22:15 ` Burn Alting @ 2015-08-21 0:14 ` Steve Grubb 0 siblings, 0 replies; 4+ messages in thread From: Steve Grubb @ 2015-08-21 0:14 UTC (permalink / raw) To: linux-audit, burn On Friday, August 21, 2015 08:15:41 AM Burn Alting wrote: > One assumes the audit_failure variable has been set in the kernel > (kernel/audit.c). Perhaps you can test this. Yes, that is where it gets written to. > Given you can get a copy of the kernel source you are running, perhaps > trace through what's happening. Using the messages > before/during/directly after the death of auditd, and what's routing to > dmesg, perhaps you can reverse engineer what is happening. > > Perhaps someone else on the list can explain why, given -f is set to 0, > and the kernel has no user space destination for audit, it still prints > (via printk()?) The explanation of what the failure flag does is explained in the auditctl man pages: "This option lets you determine how you want the kernel to handle critical errors. Example conditions where this mode may have an effect includes: transmission errors to userspace audit daemon, backlog limit exceeded, out of kernel memory, and rate limit exceeded." Note that dead audit daemon is not included in what it covers. > On Thu, 2015-08-20 at 13:17 +0300, Alex Beljanski wrote: > > We have custom audit-dispatcher for process events. On some servers > > when auditd fails, all audit messages writes to kernel. This is expected when the audit system is enabled. > > We don't want to see all this messages in dmesg and set failure flag > > to "0". This doesn't help. Correct. For _events_ to not be written to syslog, the audit system has to be disabled. You would run "auditctl -e 0" to turn off the audit system. OR if you are using rsyslog, then you can probably write a filter so that it removes audit events as it finds them. -Steve ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-08-21 0:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-20 8:09 Failure flag "0" doesn't work Alex Beljanski
2015-08-20 9:39 ` Burn Alting
[not found] ` <CAJeTBw8mAYC0RTjuVKC84tEfUVKsB+F_JASkJu4rOQVREV9DOw@mail.gmail.com>
2015-08-20 22:15 ` Burn Alting
2015-08-21 0:14 ` Steve Grubb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).