Audit - FAQ

Goss Binary Issues

Why does goss run manually fail?

Example error when running:

goss -g goss.yml -v

Goss is designed to run from the scripts passing discovered variables into Goss for metadata. Without these values being set, Goss will fail. These metadata variables can be seen towards the end of the goss.yml file. Furthermore, the run_audit script shows how these variables are created and passed to Goss.

Solution: Always use the provided run_audit.sh or run_audit.ps1 scripts.

Goss Binary Not Found

Symptom:

./run_audit.sh: line XX: /usr/local/bin/goss: No such file or directory

Solution:

Download the correct binary for your architecture:

AMD64/x86_64:

curl -L https://github.com/aelsabbahy/goss/releases/download/v0.4.9/goss-linux-amd64 \
    -o /usr/local/bin/goss
chmod +x /usr/local/bin/goss

ARM64/aarch64:

curl -L https://github.com/aelsabbahy/goss/releases/download/v0.4.9/goss-linux-arm64 \
    -o /usr/local/bin/goss
chmod +x /usr/local/bin/goss

Or update AUDIT_BIN in the script to point to the correct location.

Exec Format Error

Symptom:

goss: cannot execute binary file: Exec format error

Cause: Wrong architecture binary (e.g., x86_64 binary on ARM64 system).

Solution:

# Check your architecture
uname -m

# Download the matching binary (see above)

Goss Version Too Old

Symptom:

WARNING - Goss installed = 0.3.16, does not meet minimum of 0.4.4

Solution:

Download and install the latest version:

curl -L https://github.com/aelsabbahy/goss/releases/download/v0.4.9/goss-linux-amd64 \
    -o /usr/local/bin/goss
chmod +x /usr/local/bin/goss
goss --version

Architecture-Specific Issues

Why do I have different results between x86_64 and ARM64/aarch64 audits?

ARM64 (aarch64) and x86_64 architectures use different system call numbers and implementations. This primarily affects auditd-related controls, as ARM64 uses different syscalls for many file operations (e.g., unlinkat instead of unlink, openat instead of open).

Common causes of ARM64 audit differences:

auditd syscall rules reference x86_64-specific syscalls
Some syscalls don’t exist on ARM64
Kernel module names may differ

What to expect:

Remediation generally works identically on both architectures
Audit results will show more failures/skips for auditd-related controls on ARM64
This is expected behavior, not a bug

For detailed information on ARM64 support, workarounds, and best practices, see the ARM64/aarch64 Architecture Guide.

Audit Results and Interpretation

How Do I Read the Audit Output?

The audit produces JSON output with the following structure:

{
  "results": [],
  "summary": {
    "failed-count": 10,
    "test-count": 200,
    "total-duration": 45.2
  }
}

Key metrics:

test-count: Total controls evaluated
failed-count: Controls that failed compliance check
skipped-count: Controls skipped (disabled or not applicable)

Why Are So Many Controls Failing?

Common Causes:

System not yet remediated - Run audit after applying hardening
Controls disabled in remediation - Audit checks all controls by default
Architecture differences - ARM64 systems have expected auditd failures
Container environment - Many controls don’t apply to containers

Solution:

Ensure audit variables match your remediation configuration:

# vars/CIS.yml - should match your remediation settings
rhel10cis_rule_1_1_1_1: true
rhel10cis_rule_1_1_1_2: false  # Disabled in remediation

Why Do I Have Failures After Successful Remediation?

Common Causes:

Reboot required - Some changes only take effect after reboot
Service restart needed - Configuration changes may need service restart
Time-based controls - Password aging, log rotation need time to apply
Manual controls - Some controls require manual intervention

Solution:

Reboot the system after remediation
Wait for time-based controls to take effect
Review manual control requirements in the benchmark documentation

How Do I Filter Audit Results?

Filter by status:

# Show only failures
cat audit_output.json | jq '.results[] | select(.successful == false)'

# Show only skipped
cat audit_output.json | jq '.results[] | select(.skipped == true)'

Filter by control ID:

# Find specific control
cat audit_output.json | jq '.results[] | select(.title | contains("1.1.1"))'

Performance and Resource Issues

My system is impacted when running the audit. How can I restrict its effect?

On both Windows and Linux, you have the ability to limit the number of processes that run at the same time.

This is set using a variable as part of the playbook:

audit_max_concurrent: 20  # Default is 50

Or if running manually using the run_audit script:

./run_audit.sh -m 20

Audit Takes Too Long

Solutions:

Reduce concurrent processes:
```
./run_audit.sh -m 10
```
Skip heavy tests (filesystem scans):
```
audit_run_heavy_tests: false
```

Increase command timeout for slow systems:

audit_cmd_timeout: 120000  # milliseconds

Audit Causes High Disk I/O

Some controls scan the entire filesystem. To reduce impact:

Run during off-peak hours
Disable heavy tests if not required:
```
audit_run_heavy_tests: false
```
Consider using ionice on Linux:
```
ionice -c 3 ./run_audit.sh
```

Script and Configuration Issues

Variables File Not Found

Symptom:

Error: vars file not found at /opt/RHEL10-CIS-Audit/vars/CIS.yml

Solutions:

Verify the audit content is properly extracted:
```
ls -la /opt/RHEL10-CIS-Audit/vars/
```

Specify the vars file path explicitly:

./run_audit.sh -v /path/to/your/vars/CIS.yml

Permission Denied Running Script

Symptom:

./run_audit.sh: Permission denied

Solutions:

Make script executable:
```
chmod +x run_audit.sh
```
Run with bash explicitly:
```
bash run_audit.sh
```
Run with sudo if required:
```
sudo ./run_audit.sh
```

Output File Not Created

Symptom: Audit runs but no output file is created.

Solutions:

Check output directory permissions:

ls -la /opt/  # or your configured output directory

Specify output file explicitly:

./run_audit.sh -o /tmp/audit_output.json

Check for errors in script execution:

./run_audit.sh 2>&1 | tee audit_debug.log

Container and Special Environments

Why Do Many Controls Fail in Containers?

Containers lack many components that benchmarks assume exist:

No systemd (typically)
No bootloader
No kernel access
Limited audit capabilities

Solution:

Set container mode:

is_container: true

See Container and Docker Guide for details.