5:15 p.m.
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(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
7:14 p.m.
New subject: Failure flag "0" doesn't work
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
3410
days inactive
3411
days old
linux-audit@lists.linux-audit.osci.io
1 comments
2 participants
participants (2)
-
Burn Alting -
Steve Grubb