Arch Linux User Repository

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,

Hello,

I am trying to install this on my up to date arch installation, and I'm running into a couple of issues. Whether I used RPM or DEB from source, the instance kept crashing on startup. I used Debtap and the link to this repo, but the conversion was broken with a dependency. (config file was incomplete and binaries rejected the <client> tag.)

Thank you!

I see that since 4.14.1 the the CIS/SCA file for Arch Linux is pulled from wazuh/integrations, but nothing more is done with that file. Are there any plans for that?