On Friday, May 3, 2019 3:31:39 PM EDT Joshua Ammons wrote: > Hello, I just wanted to see if anyone has had much success with configuring > redhat systems to reduce and/or eliminate the occurrence of auid = unset > in the audit events?
auid = unset is a natural thing. Typically it indicates that a daemon has tripped over an audit rule. If you are seeing auid = unset by actions that you know a user caused, then you really want to find out how they logged in. You may have an entry point daemon that is not audit friendly. For example, login, sshd, gdm, kdm have all be modified to call the audit_setloginuid90 function. > I found the following redhat article that provides a > fix by updating a grub setting for auditd but this doesn't seem to have > much of an effect, as I still see large number of unset values in the > logs. It does. But maybe not how you think it would. You need to boot with audit=1 and audit_backlog_limit=8192 (or some number). The first setting makes sure that every process that gets launched is auditable. If this is not set, then there can be processes that would cause audit events but will never ever be detected. So, this is important. The second setting ensures that backlog is big enough to hold events until the audit daemon starts. Otherwise you can lose some events during boot. > https://access.redhat.com/solutions/971883 > > Thank you in advance for any information you may have on this. Check you events and see what process is causing them: ausearch --start today --loginuid unset --raw | aureport -x --summary See if this is mostly daemons or scripts run on behalf of daemons. The fix might be to alter the audit rules to avoid daemon activity. This is what the -F auid>=1000 -F auid!=unset does in the shipped sample rules. And this is completely expected that daemon activity auid == unset. If these are from user sessions, check how they get into the system. Something seems wrong there. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
