Rational behind RefuseManualStop=yes in auditd.service

Rational behind RefuseManualStop=yes in auditd.service

[Laurent Bigonville]

Hi,

I would like to know the rational behind RefuseManualStop=yes in
auditd.service file.

I'm currently looking at upgrading the audit package in debian and
RefuseManualStop=yes is preventing the daemon to be restarted during
upgrade.

Looking at systemd.unit(5) manpage, I don't have the feeling that it
should be used in this case.

As a side note, it seems that the *.spec file is stopping the daemon in
the %preun so this could fail I guess?

Any thoughts on this?

Laurent Bigonville

Re: Rational behind RefuseManualStop=yes in auditd.service

[Steve Grubb]

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.

Common Criteria requires that we have the identity of the user altering any 
audit settings such as whether its running or not. Systemctl uses dbus to talk 
to systemd. It in turn sends the signal to auditd. Auditd asks the kernel who 
did it and gets -1 for the answer because that's the auid of systemd.  This 
was reported as bz 881057.

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.

The long term fix is to put part of dbus in the kernel so that we can tell the 
kernel to transfer credentials from one process to another so that auditing is 
correct.


> I'm currently looking at upgrading the audit package in debian and
> RefuseManualStop=yes is preventing the daemon to be restarted during
> upgrade.
> 
> Looking at systemd.unit(5) manpage, I don't have the feeling that it
> should be used in this case.

If you don't need to meet common criteria requirements, then patch it out so 
its the way you like it.


> As a side note, it seems that the *.spec file is stopping the daemon in
> the %preun so this could fail I guess?
> 
> Any thoughts on this?

Patch any file to what makes sense for your user base. :-)

-Steve

Re: Rational behind RefuseManualStop=yes in auditd.service

[Tony Jones]

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

Re: 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

Re: Rational behind RefuseManualStop=yes in auditd.service

[Tony Jones]

On 12/18/2013 12:38 PM, Eric Paris wrote:

> 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...

This doesn't really make a lot of sense as a certifiable audit presumably also needs the local Fedora specific changes to systemd, which are not in the upstream systemd repo.   So I'd have thought the Fedora specific audit package was a perfectly suitable location for the audit changes rather than the main audit svn repo.

Anyhow, it is what it is.   We patched the changes out in our repo.

Tony

Re: Rational behind RefuseManualStop=yes in auditd.service

[Tony Jones]

On 12/18/2013 01:07 PM, Tony Jones wrote:
> On 12/18/2013 12:38 PM, Eric Paris wrote:
> 
>> 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...
> 
> This doesn't really make a lot of sense as a certifiable audit presumably also needs the local Fedora specific changes to systemd, which are not in the upstream systemd repo.   So I'd have thought the Fedora specific audit package was a perfectly suitable location for the audit changes rather than the main audit svn repo.

OIC, you were talking purely of the addition of the RefuseManualStop=yes,   Sorry,   I was talking more about the presence of utility scripts in the svn repo that are Fedora specific since they rely on Fedora systemd extensions.

Anyhow, as I said, not a big deal.  Thanks for reply.