ASIMP :: Security Platform
ANSIBLE SYSTEM INTEGRITY MANAGEMENT PLATFORM // baselines & hardening
MODE:

Documentation

Home Gitbook & dsom summary index Asimp for ai agents: deep state of mind (dsom) protocol integration Ansible execution environments (ee) & sovereign gitea integration guide Ansible best practices & fqcn standards Ansible playbook and document architecture map Architecture & design Configuration & variables Debian gnu/linux hardening & audit guide Review & adoption of dsom ansible configuration guide (v3.6.2) Diátaxis documentation framework Deep state of mind (dsom) governance framework System architecture & security posture Operational recipes index Execute tool workflows Legal notice & disclaimer Asimp local testing matrix & telemetry spec Lynis auditing & playbook analysis Openscap integration & playbook analysis The enterprise linux openscap operational guide: automated vulnerability auditing, baseline compliance, and safeguarded air gapped remediation Opensuse / suse linux enterprise hardening & audit guide Rootless podman 5+ & quadlet orchestration Asimp standard footer patcher reference Google okf frontmatter patcher reference Ansible config parameters reference Component & tool index Sovereign feedback collector reference Llm xml context compiler reference Role lynis ansible reference Mock scanning utility reference Openwiki emulator specification Sovereign os role patcher reference System core playbooks reference Jekyll pre processor reference Role reporting asimp reference Suse/sled sysctl hardening role reference Role update ubuntu asimp reference Sitemap & link integrity validator reference Enterprise linux cis level 2 audit & hardening guide Local knowledge first & metadata discovery Troubleshooting & fallback behaviors Quickstart onboarding guide Ubuntu 24.04/26.04 lts hardening & audit guide

Reports & SPA

Output of ASIMP Output of Lynis Output of OpenSCAP Portal OpenSCAP Report SPA Requirement Checklist

About ASIMP

ASIMP is an automated framework built with Ansible to assess host compliance, configure OS parameters, secure SSH, and verify integrity.

Rootless Podman 5+ & Quadlet Orchestration

Ansible >= 9.0.0 OpenSCAP: CIS L2 Lynis: Enabled debsums: Enabled

Rootless Podman 5+ & Quadlet Orchestration

In ASIMP, we embrace the security-first principle of unprivileged, rootless workload execution. While typical systems-level security testing frameworks require full superuser privileges, ASIMP separates host OS tuning from target testing environments using Rootless Podman 5+ & Systemd Quadlets.

🧭 Why Rootless Podman 5+ & Quadlets?

Containerized workloads run in parallel to test and verify ASIMP’s hardening policies. Legacy architectures rely on rootful Docker daemons, which introduce unnecessary host security exposure. Podman 5+ resolves this by converting unprivileged declarative container specifications directly into native, unprivileged systemd unit files using Quadlets (such as .container, .volume, .pod, and .network configurations).

This enables containers to be treated natively as standard local system services without daemon overhead.

⚙️ Unprivileged Environment Mappings

To safely interact with rootless systemd managers, Ansible playbooks must operate under correct environment contexts:

  • XDG_RUNTIME_DIR: Specifies the socket and runtime file storage location. For rootless execution sessions, this defaults to /run/user/<UID>.
  • DBUS_SESSION_BUS_ADDRESS: Directs client requests to the user-level D-Bus message bus socket, typically located at unix:path=/run/user/<UID>/bus.

Without these environment variables, systemctl commands executed by Ansible inside unprivileged user blocks will fail with connection errors.

🔒 Namespace Mapping & the keep-id Strategy

When running rootless containers, Podman maps internal root (UID 0) to the host user’s UID (e.g., 2001). Internal non-root container users (like UID 2001 inside the container) map to high-range subuids on the host. This complicates backup processes and permission management.

ASIMP leverages Podman’s User Namespace Mapping (UserNS=keep-id:uid=2001,gid=2001) at container and pod levels. By provisioning a dedicated unprivileged user on the host and aligning container and host permissions, we preserve storage sovereignty and absolute file permission transparency without root level interventions.

🔄 Enabling Systemd Lingering

By default, user-level systemd managers terminate when the user logs out. To allow background containers and unprivileged scanning services to survive sessions and launch on system start, lingering must be enabled:

- name: Enable systemd lingering for songket user
  ansible.builtin.command:
    cmd: "loginctl enable-linger songket"
    creates: "/var/lib/systemd/linger/songket"
  become: yes

This guarantees seamless, high-performance background execution for our unprivileged testing matrix under any context.