On Tue, 2013-12-03 at 12:16 -0800, Tony Jones wrote: > On 07/30/2013 01:25 PM, Steve Grubb wrote: > > On Tuesday, July 30, 2013 10:04:46 PM Laurent Bigonville wrote: > >> Hi, > >> > >> I would like to know the rational behind RefuseManualStop=yes in > >> auditd.service file. > > > > The short term "fix" is to force admins to use the service command which > > loads > > legacy helper scripts which are pulled from the old SysV init script. It > > sends > > signals in the user's context so that the auid is correct. > > You mean this? > https://lists.fedoraproject.org/pipermail/devel/2012-June/169411.html > > The problem is that (I believe) this feature isn't in upstream systemd, > rather it's Fedora specific. > > > If you don't need to meet common criteria requirements, then patch it out > > so its the way you like it. > > If I'm correct and the above is Fedora specific, I would have thought the > better option was to not use such extensions in the audit svn codebase; > rather patch them *in* via the Fedora rpms. Or make it configure tuneable. > > Tony
There is supposedly a requirement in some govt certification document that I couldn't quote to save my life, which says that auditd must record some information about the process which stopped auditd. Before systemd, admins, using sysint scripts would send a signal to auditd telling it to die. The kernel, on EVERY SINGLE SIGNAL EVER SENT, checks to see if the signal is being sent to auditd. (yes, this is completely bat shit insane, but I didn't build this horrific mess). In any case, when the kernel sees a signal is going to be delivered to auditd it records information about the sending process. When auditd gets the signal from the kernel it then polls the kernel to get the information about the sending process. auditd then records that information and shuts down as fast as it can. Along came systemd. Now when an admin types, systemctl stop auditd.service, it is pid 1 which sends the signal to auditd, not the shell of the admin in question. So the kernel stores info about pid 1 and then when auditd polls and asks where the signal came from it always got pid 1. systemd itself logs (in the audit log) who starts and stops services but, my understanding is that it has no reliable way to collect all of the information about the calling task necessary. Nor did steve want to consider init to be part of the trust chain for that information. He made the change in the upstream repo, because that's what you need for certification purposes. Personally, I hate it, cause i don't give a hoot about that and would rather things to be consistent, but that's the rational. A certifiable audit needs what he has in the repo. If we ever get all of the credential data available to systemd it can be reverted... -Eric -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit