Arch Linux User Repository

Hmm. The patching process is trying to work on the symlink in src instead of the file that the symlink points to.

If we add --follow-symlinks in the patch command (in PKGBUILD), it works correctly.

Thanks a lot Richard Soti and willymdv for the detailed reports — all of it landed in 4.14.6-1.

== SCA (cis_arch_linux.yml) == The SCA policy is pulled from upstream (wazuh/integrations) and pinned by checksum, so I couldn't just edit the file in-tree — it would be overwritten on every rebuild. Instead the fixes now ship as a local patch applied in prepare() (cis_arch_linux-arch-derivatives.patch). I'll also open a PR upstream so this eventually becomes unnecessary.

Applied: - OS detection (line 31): the whole policy was being skipped on Arch-based distros. Fixed to match EITHER id, so it works on Arch AND derivatives from a single file — no separate CachyOS copy needed: f:/etc/os-release -> r:^ID=arch|^ID_LIKE=arch Note: I did NOT use r:ID_LIKE=arch alone, since pure Arch has no ID_LIKE field in /etc/os-release and that would have skipped the policy on Arch itself. Confirmed on CachyOS: /etc/arch-release is present (from the filesystem package) and ID_LIKE=arch, so the requirements block passes.

• Root-cause "not c:<cmd>" without a pattern (thanks willymdv for the great write-up). Paired every affected rule with an explicit pattern:
  • 8003 prelink, 9001 xinetd, 9002 openbsd-inetd -> added -> r:^<pkg>
  • 9003, 11001-11008 -> added -> r:^enabled$
  • also fixed 11003 (vsftpd/proftpd) and 12001 (postfix/sendmail), same latent bug
• 7005: accept static as valid for systemd-tmpfiles-clean.timer: -> r:^enabled$|^static$
• 8001: dropped the unreliable systemctl show | grep rule; now a direct check on /etc/systemd/coredump.conf (Storage=none + ProcessSizeMax=0)
• 13002/13003/13004 (/tmp nodev/nosuid/noexec): switched to condition: any and added a findmnt -kn /tmp fallback, keeping mount for bare metal

One I intentionally skipped: the SigLevel change (7001/19001). The package already uses r:^SigLevel.*Required, which is more permissive than the proposed \s=\s form (that one would fail on SigLevel=Required with no spaces, or with tabs), so I kept the existing rule.

== ossec.conf == Added Richard's journald collector so PAM auth / sudo / pacman / kernel events are captured out of the box:

<localfile>
  <log_format>journald</log_format>
  <location>journald</location>
</localfile>

Thanks again both — really appreciate the quality reports. Keep them coming!

Additional fixes to cis_arch_linux.yml

Following the previous set of fixes, here are more checks that were failing due to the same pattern matching bug in the Wazuh SCA engine.

Root cause (same bug, multiple checks)

not c:command without a -> r:pattern clause fails whenever the command produces any output — even disabled, not-found, or an error message. The fix is to always pair not c: with an explicit pattern so the check only fails when the output matches what actually indicates non-compliance.

Checks 9001 / 9002 — xinetd / openbsd-inetd not installed

When a package is absent, pacman -Q <package> exits non-zero and outputs an error string. Without a pattern, not c:pacman -Q xinetd fails because there is output.

• not c:pacman -Q xinetd -> r:^xinetd
• not c:pacman -Q openbsd-inetd -> r:^openbsd-inetd

Checks 11001–11008 — unused services not enabled

systemctl is-enabled always produces output (disabled, not-found, static, etc.), so not c:systemctl is-enabled <service> without a pattern always fails regardless of the actual service state.

Fixed by adding -> r:^enabled$ to every rule in these checks:

# 11001
- not c:systemctl is-enabled nfs-server -> r:^enabled$
- not c:systemctl is-enabled rpcbind -> r:^enabled$ # 11002
- not c:systemctl is-enabled named -> r:^enabled$ - not c:systemctl is-enabled bind9 -> r:^enabled$
# 11004 - not c:systemctl is-enabled httpd -> r:^enabled$
- not c:systemctl is-enabled apache2 -> r:^enabled$ - not c:systemctl is-enabled nginx -> r:^enabled$
# 11005 - not c:systemctl is-enabled dovecot -> r:^enabled$
# 11006
- not c:systemctl is-enabled smb -> r:^enabled$ - not c:systemctl is-enabled nmb -> r:^enabled$
# 11007 - not c:systemctl is-enabled squid -> r:^enabled$
# 11008
- not c:systemctl is-enabled snmpd -> r:^enabled$

Check 9003 — Legacy network services
not c:command without a pattern fails whenever the command produces any output, even disabled or not-found. Added -> r:^enabled$ so the check only fails if a service is actually enabled.

• not c:systemctl is-enabled telnet.socket -> r:^enabled$
• not c:systemctl is-enabled rsh.socket -> r:^enabled$
• not c:systemctl is-enabled rlogin.socket -> r:^enabled$
• not c:systemctl is-enabled vsftpd -> r:^enabled$

Same fix applied to the duplicate vsftpd check (near check 749).

Checks 13002 / 13003 / 13004 — nodev / nosuid / noexec on /tmp

c:mount produces very verbose output on systems with many overlay/container mounts. The regex can fail to match even when the option is present. Added findmnt as an alternative and switched to condition: any so either rule can satisfy the check. The original mount rule is kept for compatibility on bare-metal installs.

condition: any
rules:
- c:mount -> r:/tmp.*nodev # bare metal fallback - c:findmnt -kn /tmp -> r:nodev
(same pattern for nosuid and noexec)

Line 31 — OS detection
The original check uses ID=arch, but Arch-based distributions declare themselves via ID_LIKE=arch in /etc/os-release. Without this fix, the entire policy is skipped.

• f:/etc/os-release -> r:ID_LIKE=arch

Check 7005 — systemd-tmpfiles-clean.timer
On Arch, systemd-tmpfiles-clean.timer reports as static, not enabled. Both states are valid and mean the unit is active.

• c:systemctl is-enabled systemd-tmpfiles-clean.timer -> r:^enabled$|^static$

Check 8001 — Core dump restriction
The original rule uses systemctl show which is unreliable in some environments. Replaced with a direct file check against /etc/systemd/coredump.conf.

• f:/etc/systemd/coredump.conf -> r:^Storage=none
• f:/etc/systemd/coredump.conf -> r:^ProcessSizeMax=0

Check 8003 — Prelink not installed
not c:command without a pattern fails whenever the command produces any output. Added an explicit pattern so the check only fails if prelink is actually installed.

• not c:pacman -Q prelink -> r:^prelink

Checks 488 and 19001 — pacman SigLevel
The original pattern Required\s+DatabaseOptional does not match a standard Arch pacman.conf where SigLevel = Required. Simplified to match what is actually present.

• f:$pacman_conf -> r:^SigLevel\s=\sRequired

I see that with 4.14.2-r2 the CIS/SCA file added earlier is now actually being used, thanks. That was the part that didn't initially make any sense to me.

@sells I'm working to resolve this issue with the Arch Linux package installation. In the meantime, if you're coming from an older installation, the package creates a backup of your current ossec.conf file, which you can restore by changing the pacsave file extension.

Tried this current version and the ossec.conf file was not present.

Hi @wunit-adf,

Yes, starting with this version an unofficial CIS/SCA file for Arch Linux is being added as a hardening guideline for base Arch systems.

I’m personally maintaining this file. At the moment, it is automatically installed only when upgrading from a version prior to 4.14.1. Once installed, it can be consulted through the agent view under CIS Benchmarks, and it will be updated over time as new hardening rules are identified from the official CIS benchmarks and adapted to Arch.

It’s important to clarify that this is a community-maintained, non-official CIS policy. It is not enabled by default as an official benchmark, and its purpose is to provide guidance and coverage for Arch users while acknowledging the rolling-release nature of the distribution.

Future updates will continue to refine and expand the ruleset based on upstream CIS guidance and practical hardening considerations for Arch Linux.

Hello @ReallyLoudFan,

Yes, we are already aware of this issue. I personally reported it to the staff.

During the update to version 4.14.1, the ossec.conf file is being deployed empty, and as a consequence, the service fails during startup after installation. This is a known regression.

This behavior is expected to be fixed in the upcoming 4.14.2 release.

As a temporary workaround, the package is configured so that when upgrading over an existing installation, a backup of the previous configuration is created. You can try restoring that backup by simply reverting the file extensions.

If this is a fresh installation and no backup is available, you will need to manually recreate ossec.conf using the generic agent configuration and complete it according to the Wazuh documentation, specifically the agent installation section.

Thank you for reporting this and for your patience.

Best regards,