Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1768815 - don't pull initscripts again
Summary: don't pull initscripts again
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: audit
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sergio Correia
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2029105 (view as bug list)
Depends On:
Blocks: IoT 1937354
TreeView+ depends on / blocked
 
Reported: 2019-11-05 10:06 UTC by Harald Reindl
Modified: 2022-10-25 09:45 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1937354 (view as bug list)
Environment:
Last Closed: 2022-10-25 09:45:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Harald Reindl 2019-11-05 10:06:31 UTC Comment hidden (abuse)
Comment 1 Steve Grubb 2019-11-05 13:48:35 UTC
Audit has always required that shutdown requests are in the user context. We absolutely have to log who is trying to alter the audit trail. This has been the case since 2004 and due to regulatory compliance that many people have to follow, we cannot change. There has been some discussion on bug 1727058 (which I am likely to close this as a duplicate of) about maybe a solution. But I doubt systemd will change. In the meanwhile, at least we don't have a dependency on chkconfig any more. :-)

Comment 2 Harald Reindl 2019-11-05 14:35:17 UTC Comment hidden (abuse)
Comment 3 Harald Reindl 2019-11-05 14:51:03 UTC Comment hidden (abuse)
Comment 4 Steve Grubb 2019-11-05 15:43:21 UTC
audit is not a mandatory package. Just remove it. As best I can tell, setroubleshoot-server is what requires it and nothing more. But this release fixed a dependency that was always there. Previously it was mistakenly placed on chkconfig.

Comment 5 Harald Reindl 2019-11-05 16:18:43 UTC
[root@testserver:~]$ rpm -e audit
error: Failed dependencies:
        audit is needed by (installed) lynis-2.7.5-4.fc30.noarch

Comment 6 Lukáš Nykrýn 2020-01-28 14:40:15 UTC
Any chance that the specification could be changed? The current state really does not make much sense. You can't directly tell systemd to stop audit, but you can do that indirectly. Just try: systemd-run -p "Conflicts=auditd.service" /bin/true

Comment 7 Steve Grubb 2020-01-28 15:03:48 UTC
What do you mean, it doesn't make sense? :-)  The requirement is that we have to record who tampers with the audit trail. This is required by common criteria, pci-dss, DISA STIG, and virtually all security standards.

Wrt to the suggestion in comment #6, this is what results in the logs:

type=DAEMON_END msg=audit(01/28/2020 09:51:03.863:5558) : op=terminate auid=root pid=1 subj=system_u:system_r:init_t:s0 res=success

Using service command, we get this:

type=DAEMON_END msg=audit(01/28/2020 09:50:50.786:6323) : op=terminate auid=sgrubb pid=13675 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=success

Both the auid and subj are correct when using service command.

If there was a way for systemctl to directly send a signal to a pid when the service says to do so, that would solve the problem. But also, what would we do about the other service commands (all signal driven): rotate, resume, state-report, and reload? Auditd has very specific rules around log rotation and resuming logging. We have to know who issues those commands. The state report is a useful diagnostic tool to understand what auditd sees in its world. This one does not need to capture who run it as it does not alter the audit trail or configuration. But reloading the audit daemon's config does.

Comment 8 Steve Grubb 2020-01-28 16:46:18 UTC
Note that on bug 1727058 comment #22 and later, it seemed like a solution was being considered. As I said in the other bug, I am not insisting that the solution must be initscripts. I'm will to change that. But I need something that meets requirements.

Comment 9 Harald Reindl 2020-01-28 18:58:05 UTC Comment hidden (abuse)
Comment 10 Lennart Poettering 2020-03-03 10:26:34 UTC
I am sorry, but these requirements are just weird: systemctl/service is just *one* command for changing state of auditd here, among many. Any client can do this via the bus API, and there are plenty which do, for example Cockpit, which we ship as part of RHEL. This means generation of the audit msg must be the service manager, not the client that generates these records, because there are so many different clients. But this means the audit msgs are generated by PID 1, i.e. as root. Which is what you are currently seeing.

A long time ago there were discussions about extending audit to allow a "on-behalf-of" field or something, so that PID 1 can fill in the client's identity there. But this never materialized, audit is kinda stalled in the upstream kernel?

Anyway, we can make PID 1 generate augmented records, but this requires preparation from the audit system for these fields which never happened. We cannot move generation to the client side, and doing that in the /usr/sbin/service command is just entirely bogus, because noone uses that anymore except of legacy sysv stuff.

So, it boils down to: do you actually care the record is properly generated always and unconditionally, i.e. reagrdless how exactly audit is started, which client is used, or do you just care about theatre, that when the legacy sysv command is started the msg is generated properly, but not when any more modern command is used nothing happens?

Anyway, it sucks that audit is in the base OS even though it's kinda stuck like this.

Comment 11 Lennart Poettering 2020-03-03 10:36:27 UTC
> If there was a way for systemctl to directly send a signal to a pid when the service says to do so, that would solve the problem. 

Just to make this very clear: this is not going to happen. systemctl is one client to systemd among many. Adding any such killing to the client side is not going to happen, and makes no sense at all. systemd is a client/server system, where the server maintains the services, and operates on the client's requests. And there are a variety of clients, systemctl and Cockpit are two prominent ones. Keeping a dependency on initscripts makes *no* sense already, simply because the /usr/bin/service tool is *not* *called* *by* *anyone* anymore, except for maybe some legacy sysv scripts. It is not called at boot for starting audit, and not called at shutdown when stopping audit. It's called by essentially noone. So why keep this dependency in? You just annoy everyone, without doing anything good. The ship on /usr/sbin/service has sailed.

> But also, what would we do about the other service commands (all signal driven): rotate, resume, state-report, and reload? Auditd has very specific rules around log rotation and resuming logging. We have to know who issues those commands. The state report is a useful diagnostic tool to understand what auditd sees in its world. This one does not need to capture who run it as it does not alter the audit trail or configuration. But reloading the audit daemon's config does.

Add your own tool for this, this has nothing to do with generic service management. Add a tool "auditcmd" or so that exposes these verbs if you need that. apache is doing something similar: the service file just starts/stops/restarts/reloads apache, i.e. the generic commands, for anything apache specific there's apachectl.

Comment 12 Xose Vazquez Perez 2022-03-30 18:40:39 UTC
*** Bug 2029105 has been marked as a duplicate of this bug. ***

Comment 13 Timothée Ravier 2022-10-25 09:45:05 UTC
I think that this has been "fixed" (or at least fixed enough for now by requesting only the service binary and not the full initscript package) with https://src.fedoraproject.org/rpms/audit/c/a010d46984a37a63675ba28e3c1322950d15b866?branch=rawhide which is 9 months old now so I'll close this one.


Note You need to log in before you can comment on or make changes to this bug.