Lynis Auditing & Playbook Analysis

Lynis is an open-source, host-based security auditing tool designed for Unix-based operating systems. It scans configurations, filesystems, kernel settings, and services to compute an overall Hardening Index (HI) rating between 1 and 100.

Within ASIMP, Lynis works in tandem with OpenSCAP as the second auditing engine. It plays a dual role: first, measuring the baseline hardening index (Phase 1); and second, executing fine-grained remediation configurations and measuring the final improved score (Phase 3).

🧭 Integration Flow in ASIMP

Lynis is coordinated through two primary roles:

1. reporting-ASIMP: Installs Lynis, executes the audit scan, parses the resulting hardening index, saves baseline metrics, and generates side-by-side terminal scorecards.
2. lynis-ansible: Standardizes Lynis packages and applies specific system hardening rules based on Lynis scanning suggestions.

⚙️ Ansible Playbook Analysis: Step-by-Step

The Lynis task definitions in ASIMP are structured across roles/reporting-ASIMP/tasks/main.yml, play-localhost.yml, and the lynis-ansible role folder. Let’s analyze the execution flow:

1. Installation of Lynis

Before running audits or applying configurations, ASIMP ensures that Lynis is available on the target host. For privileged production environments, this is completed via the standard package manager:

- name: Ensure lynis is installed
  ansible.builtin.package:
    name: lynis
    state: present
  ignore_errors: yes
  when: not (is_sandbox_jules | default(false) | bool)

For unprivileged sandboxes, package installation is skipped to prevent connection and privilege errors.

2. Execution of System Audit (--quick mode)

To establish a baseline and verify improvements, the playbook invokes the Lynis command-line utility. The --quick option prevents the scanner from blocking or waiting for user inputs during automated execution:

- name: Run Lynis BEFORE hardening audit
  ansible.builtin.shell: lynis audit system --quick --report-file {{ openscap_report_dir }}/lynis-report-before.dat
  register: lynis_before_run
  failed_when: false
  changed_when: true

The scan saves a detailed machine-readable audit report to lynis-report-before.dat (or lynis-report-after.dat post-hardening).

3. Parsing and Extracting the Hardening Index

The overall system score calculated by Lynis is stored in the .dat report file under the variable key hardening_index. ASIMP extracts this score using a standard shell utility:

- name: Parse Lynis BEFORE hardening index
  ansible.builtin.shell: grep -E "^hardening_index=" {{ openscap_report_dir }}/lynis-report-before.dat | cut -d'=' -f2
  register: parsed_lynis_before
  changed_when: false
  failed_when: false

• If successful, the index number is extracted and structured.
• For the baseline phase, this score is written to the /var/log/asimp-baseline-scores.json metadata file so it can be slurped and compared during Phase 3.

4. Applying Hardening Configuration Remediations

ASIMP implements standard configuration-level mitigations mapped from Lynis’s best practices. In Phase 2, the lynis-ansible role is loaded to lock down common risk surfaces:

- name: Apply Lynis Hardening Configuration
  block:
    - name: Apply Lynis Hardening Configuration
      ansible.builtin.include_role:
        name: lynis-ansible
      vars:
        lynis_use_packages: true
        lynis_audit_system_linux: true
  ignore_errors: "{{ is_sandbox_jules }}"
  when: asimp_privilege_level == 'full'
  become: true

These tasks apply fine-grained parameters:

• Hardening permissions on shadow files and directories.
• Securing kernel variables (disabling IP forwarding, enforcing SYN flood protection).
• Disabling unused or insecure legacy filesystem mounts and protocols (e.g., USB storage, DCCP).
• Restricting compilers and shells to administrative accounts.

🐳 Unprivileged Sandbox & Mock Execution Mode

In restricted execution contexts (such as the containerized Google Jules sandbox), raw system auditing commands might fail or report inaccurate values due to limited kernel namespaces and access policies.

To bypass these limitations gracefully:

1. Tool Check: ASIMP tests if the lynis binary is pre-installed in the environment using which lynis.
2. Execution Gate: If present, it executes the scan. If not present or restricted, it falls back to a simulated score.
3. Simulated Hardening Progress (NON-AUTHORITATIVE & TEST-ONLY): If running in sandbox fallback, ASIMP simulates realistic, compliant scoring data:
   • Baseline Hardening Index: 62 / 100
   • Post-Hardening Index: 88 / 100
   • Important Note: These simulated/mock fallback scores and any derived “Compliant” or “Non-vulnerable” reports are strictly non-authoritative and test-only data. They are preserved strictly for sandbox test verification and CI/CD logical consistency.
4. Downstream Compliance Gate Behavior: To prevent any security bypasses, downstream compliance-gate verification explicitly rejects simulated/mock results. Simulated executions will fail to satisfy any actual compliance checkpoints (i.e. lynis_success and audits_completed are set to false when simulated fallbacks are used), ensuring only real, verified audits can validate a system’s true security baseline.
5. Unified Scorecard Storage: The parsed or simulated score is saved into data/asimp_mock/var/log/asimp-baseline-scores.json and printed on the final terminal report. This ensures that CI/CD and sandbox environments remain green while verifying overall playbook logical consistency.