Bug 2258520 - systemd presets request - audit-rules.service
Summary: systemd presets request - audit-rules.service
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-01-15 19:40 UTC by Steve Grubb
Modified: 2024-01-15 21:21 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-01-15 21:21:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Steve Grubb 2024-01-15 19:40:17 UTC
* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)?

Yes and no. Fesco asked under bug 1117953 to have auditing minimize the effects of the audit system by default. As such, installation of the rpm causes the 10-no-audit.rules file to be placed at the default rules. This puts the audit system in an optimal state that is more performant than simply not loading rules at all. It loads a rule that short circuits auditing at process fork so that each syscall is not examined before deciding nothing of interest here. We would continue loading the same rule - no change.

* Does the service listen on a network socket for connections originating on a separate physical or virtual machine?

No.

* Is the service non-persistent (i.e. run once at startup and exit)?

Yes. It loads the audit rules and terminates.

* What is the exact name (or names) of the systemd unit files to be enabled?

audit-rules.service

* Is this request for all Fedora deliverables or only for some Editions (list them)?

All.

One last note, auditd was enabled as a preset under FESCo - https://fedorahosted.org/fesco/ticket/1311. The same reason it was needed to be a preset then is the same as now. The audit daemon loaded the rules in the past. But eventaully it was noticed that there was a problem where system events that were of interest occurred before auditd could start. Splitting them allows the rules to load sooner so the events are waiting when auditd registers with the kernel.

The secondary effect of this split is that some people may be satisfied with audit events in journald. This would let them have auditing without having to install auditd and it man pages and utilities. It certainly won't have search and report capabilities. But they may be offloading events to a central SIEM and don't care.

Comment 1 Stephen Gallagher 2024-01-15 20:38:35 UTC
(In reply to Steve Grubb from comment #0)
> * Does the service require post-rpm-installation configuration in order to
> be useful (for example, does it need manual edits to a configuration file)?
> 
> Yes and no. Fesco asked under bug 1117953 to have auditing minimize the
> effects of the audit system by default. As such, installation of the rpm
> causes the 10-no-audit.rules file to be placed at the default rules. This
> puts the audit system in an optimal state that is more performant than
> simply not loading rules at all. It loads a rule that short circuits
> auditing at process fork so that each syscall is not examined before
> deciding nothing of interest here. We would continue loading the same rule -
> no change.
> 

This is just a "no". The purpose of this question is to avoid issues where installing a package with an enabled preset would cause errors because the user didn't also manually update the config before rebooting.

I've created https://src.fedoraproject.org/rpms/fedora-release/pull-request/300 for this (lucky PR number!). Please confirm that it all looks good and I'll merge and build it.

Comment 2 Steve Grubb 2024-01-15 21:05:14 UTC
OK. I see. Yes, the pull request looks good. I suppose this change should land first? Otherwise there might be a hiccup where people have to manually enable the service if the new auditd lands first.


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