From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Grubb <sgrubb@redhat.com>
Subject: Re: Rational behind RefuseManualStop=yes in auditd.service
Date: Tue, 30 Jul 2013 16:25:06 -0400
Message-ID: <3276481.Os0RojCrYf@x2>
References: <20130730220446.0dced4f5@fornost.bigon.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
In-Reply-To: <20130730220446.0dced4f5@fornost.bigon.be>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: linux-audit@redhat.com
List-Id: linux-audit@redhat.com

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