hardening-script-el6
hardening-script-el6 copied to clipboard
fcaviggia
auditd kernel panic
I've configured a RHEL 6 box with Oracle HTTPD (and an oracle app) that continuously suffers from kernel panic. Majority of the audit events are similar to below.
type=SYSCALL msg=audit(1443487841.513:2456187): arch=40000003 syscall=75 per=400008 success=yes exit=0 a0=4 a1=ffebed60 a2=f7702478 a3=8a481b0 items=0 ppid=2986 pid=3146 auid=2642 uid=1001 gid=1000 euid=1001 suid=1001 fsuid=1001 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="httpd" exe="/path/to/Apache/bin/httpd" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
it almost seems as thought he default settings are little too stringent. I'm currently trying to resolve the issue on my own but it's not as easy as I was hoping.
While I don't support Oracle, you might try increasing the buffer size dramatically - 16384KB was just a starting point, what is yours currently set at?
I don't think it's a matter of oracle as much as it is apache constantly being written to the audit daemon. I've increased the buffer/log size (since logs were being rotated too rapidly) though that'll just increase the space consumption on the audit partition.
I just wasn't sure if it was a rule configuration that I could change to stop when a worker gets started up from being constantly audited and written.
I have something similar where my audit.rules audit everything when auid is above 500. If services are started by init.d, their auid=1, when started by another user, either via su or sudo the auid is above 500. I havn't found a resolution for RHEL6, but RHEL7 the services are always started by systemd, and therefore auid=1.
On Tue, Sep 29, 2015 at 2:25 PM spitefultowel [email protected] wrote:
I just wasn't sure if it was a rule configuration that I could change to stop when a worker gets started up from being constantly audited and written.
— Reply to this email directly or view it on GitHub https://github.com/fcaviggia/hardening-script-el6/issues/58#issuecomment-144146295 .
So it's on the application side of the house... Sadly given that we want custom control and things aren't service based but rather independently compiled apps, we want the IDs at 1k+.
Then identify the auditd rule that is causing them to be generated and modify it. According to the auditd output provided, it doesn't have a "-k something" statement which should limit the number of rules that it could probably be.
I am actually about to throw out all the "required" audit rules, since the compliance analysis (openscap,scc,nessus) only do static string comparison, vice proper analysis to see if audit criteria exists.
On 9/30/15 10:06 AM, Curtis Ruck wrote:
I am actually about to throw out all the "required" audit rules, since the compliance analysis (openscap,scc,nessus) only do static string comparison, vice proper analysis to see if audit criteria exists.
Here's the way the STIG audit rules were written (specifically, the regex that looks for various config options): https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/audit_rules_dac_modification_fchmod.xml#L56#L60
The regex tries to find only the appropriate audit config. What would you consider proper analysis? Feedback would be extremely welcome -- we certainly don't want to ship untenable rules that cause excessive alerts, or are found to be so poorly written they're tossed out!
