Rational behind RefuseManualStop=yes in auditd.service

[Eric Paris]

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