Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Noisy plugin termination at shutdown #272

Closed
cgzones opened this issue Aug 4, 2022 · 11 comments
Closed

Noisy plugin termination at shutdown #272

cgzones opened this issue Aug 4, 2022 · 11 comments
Labels

Comments

@cgzones
Copy link
Contributor

cgzones commented Aug 4, 2022

Following the example plugin code from https://github.com/linux-audit/audit-userspace/blob/master/contrib/plugin/audisp-example.c

        [...]
        /* Flush any accumulated events from queue */
        auparse_flush_feed(au);
        auparse_destroy(au);
        if (stop)
                syslog(LOG_INFO, "sedispatch is exiting on stop request");
        else
                syslog(LOG_INFO, "sedispatch is exiting on stdin EOF");

        return 0;
}

auditd complains roughly in 1 of 4 shutdowns:

Aug 04 12:26:19 dlaptop sedispatch[864]: sedispatch is exiting on stop request
Aug 04 12:26:19 dlaptop auditd[862]: plugin /usr/sbin/sedispatch terminated unexpectedly
Aug 04 12:26:19 dlaptop auditd[862]: plugin /usr/sbin/sedispatch was restarted
Aug 04 12:26:19 dlaptop sedispatch[5277]: sedispatch is exiting on stdin EOF
@stevegrubb
Copy link
Member

Hmm. I'll look at this. I guess the message should be qualified with the stop flag.

@stevegrubb stevegrubb added the bug label Aug 5, 2022
@stevegrubb
Copy link
Member

What version of auditd are you using?

@stevegrubb
Copy link
Member

I added a qualifier to the "terminated unexpectedly" message, but I can't see how the "was restarted" message is sent because the whole restart code block is qualified by !stop.

@cgzones
Copy link
Contributor Author

cgzones commented Aug 17, 2022

Originally observed with 3.0.7, but also reproducible with 3.0.8.

Using KillMode=mixed in the [Service] section of auditd.service seems to solve this issue, as systemd by default sends on stop SIGTERM to all processes in the control group of this unit, thus the plugins can exit before the main auditd process changes the stop flag.
See https://www.freedesktop.org/software/systemd/man/systemd.kill.html

@stevegrubb
Copy link
Member

That explains why I'm not seeing it. The default audit.service file does not allow systemctl to kill the daemon. This is because it uses dbus which hides who terminated the audit daemon. The only known solutions are using service auditd stop or auditctl --signal TERM. OK, I guess we can close this out.

@cgzones
Copy link
Contributor Author

cgzones commented Aug 19, 2022

@stevegrubb
Copy link
Member

Yes. That is allowing the default behavior of killing everything instead of letting auditd manage the shutdown. Your suggested fix is likely an improvement to their patch.

@bigon
Copy link
Contributor

bigon commented Aug 29, 2022

Hello,

I think that this bug must be reopened and fixed upstream.

The option that I removed is called RefuseManualStop= that means that systemd would not allow a manual stop of the service, but it will stop auditd automatically during shutdown/reboot.

@stevegrubb
Copy link
Member

Common Criteria requires that we collect the auid of anyone interacting with the audit daemon. So, we need the signal to come directly from the user context. The audit system queries the kernel to see who did it. The answer it gets is invalid if systemctl was used.

@bigon
Copy link
Contributor

bigon commented Aug 30, 2022

@stevegrubb yes I know that, I'm not telling that you need to remove RefuseManualStop=

I'm saying that, during shutdown/reboot (and also in some other conditions where auditd is indirectly stopped), systemd WILL send a SIGTERM signal to all the processes in the cgroup

If you want auditd to terminate the plugins itself when it receives SIGTERM you need to change the KillMode= like @cgzones suggested.

@bigon
Copy link
Contributor

bigon commented Oct 14, 2022

Any more thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants