* Rational behind RefuseManualStop=yes in auditd.service
@ 2013-07-30 20:04 Laurent Bigonville
2013-07-30 20:25 ` Steve Grubb
0 siblings, 1 reply; 6+ messages in thread
From: Laurent Bigonville @ 2013-07-30 20:04 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational behind RefuseManualStop=yes in auditd.service
2013-07-30 20:04 Rational behind RefuseManualStop=yes in auditd.service Laurent Bigonville
@ 2013-07-30 20:25 ` Steve Grubb
2013-12-03 20:16 ` Tony Jones
0 siblings, 1 reply; 6+ messages in thread
From: Steve Grubb @ 2013-07-30 20:25 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational behind RefuseManualStop=yes in auditd.service
2013-07-30 20:25 ` Steve Grubb
@ 2013-12-03 20:16 ` Tony Jones
2013-12-18 20:38 ` Eric Paris
0 siblings, 1 reply; 6+ messages in thread
From: Tony Jones @ 2013-12-03 20:16 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational behind RefuseManualStop=yes in auditd.service
2013-12-03 20:16 ` Tony Jones
@ 2013-12-18 20:38 ` Eric Paris
2013-12-18 21:07 ` Tony Jones
0 siblings, 1 reply; 6+ messages in thread
From: Eric Paris @ 2013-12-18 20:38 UTC (permalink / raw)
To: Tony Jones; +Cc: linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational behind RefuseManualStop=yes in auditd.service
2013-12-18 20:38 ` Eric Paris
@ 2013-12-18 21:07 ` Tony Jones
2013-12-18 21:16 ` Tony Jones
0 siblings, 1 reply; 6+ messages in thread
From: Tony Jones @ 2013-12-18 21:07 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-audit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational behind RefuseManualStop=yes in auditd.service
2013-12-18 21:07 ` Tony Jones
@ 2013-12-18 21:16 ` Tony Jones
0 siblings, 0 replies; 6+ messages in thread
From: Tony Jones @ 2013-12-18 21:16 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-audit
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-18 21:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-30 20:04 Rational behind RefuseManualStop=yes in auditd.service Laurent Bigonville
2013-07-30 20:25 ` Steve Grubb
2013-12-03 20:16 ` Tony Jones
2013-12-18 20:38 ` Eric Paris
2013-12-18 21:07 ` Tony Jones
2013-12-18 21:16 ` Tony Jones
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox