From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Rational behind RefuseManualStop=yes in auditd.service
Date: Tue, 30 Jul 2013 16:25:06 -0400 [thread overview]
Message-ID: <3276481.Os0RojCrYf@x2> (raw)
In-Reply-To: <20130730220446.0dced4f5@fornost.bigon.be>
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
next prev parent reply other threads:[~2013-07-30 20:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 20:04 Rational behind RefuseManualStop=yes in auditd.service Laurent Bigonville
2013-07-30 20:25 ` Steve Grubb [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3276481.Os0RojCrYf@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox