Open pcmoore opened 8 years ago
pcmoore
commented
8 years ago I suspect this may be an issue with using the shared printk_ratelimit() limiter in audit_printk_skb() and audit_log_lost(); we probably should implement an audit specific rate limit to prevent other subsystems from squelching audit messages, especially those in audit_log_lost().
pcmoore
commented
7 years ago Quick follow up, printk_ratelimited() is likely what we want to use as the next step.
rgbriggs
commented
6 years ago Has this issue been solved by https://github.com/linux-audit/audit-kernel/issues/66 ("BUG: the kernel does not initialize audit before forking PID 1") ?
pcmoore
commented
6 years ago Has this issue been solved by #66 ("BUG: the kernel does not initialize audit before forking PID 1") ?
That is obviously a source of potentially missed audit records, but read the subject line and my previous comments carefully; the issue pertains to early boot, the issue fixed in #66 affected PID 1 throughout the process' lifetime and not just early boot.
I may be wrong, but based on a quick inspection, I believe the rate limiter is to blame.
stevegrubb
commented
6 years ago What was the setting for audit_backlog_limit on the kernel boot command line?
pcmoore
commented
6 years ago What was the setting for audit_backlog_limit on the kernel boot command line?
Unknown. This problem was reported to me in person so I don't have any additional information beyond what is already mentioned in this issue.
As mentioned previously, at this point in time I believe this is an issue with the printk ratelimiter and not the audit backlog setting.
On occasion SELinux AVC denials are dropped by the audit subsystem during early boot without any warnings about dropped audit records. This was reported as an issue with Android kernels but it is expected to be a problem with standard kernels as well.