Skip to content
API Documentation
BastionGuard™
Validation status — RootGuard 2.5.3

Validated in the artifact environment:

  • CMake configure, build and CTest with daemon and GTK components disabled;
  • rootguard-policy-tests, including trusted-application parsing and conflict validation;
  • rootguard-file-identity-tests;
  • rootguard-event-tests, including actor and path-resolution fields;
  • warning-enabled C++17 syntax checks for the daemon engine with generated libbpf/skeleton stubs;
  • warning-enabled C++17 syntax checks for the action helper, service response, JSON sink, client and tabbed GTK page;
  • action-helper atomic policy rewrite for trusted, privilege-trusted and denied application rules;
  • CMake staged installation preserving an existing rootguard.conf;
  • CMake configuration for systemd, OpenRC, dinit, SysV init and none;
  • shell syntax for helper and init scripts;
  • XML parsing of the polkit policy.

Target-system validation still required:

  • generation of vmlinux.h from the target kernel BTF;
  • Clang BPF compilation, bpftool skeleton generation and verifier acceptance;
  • full GTK4/gtkmm compilation inside the BastionGuard source tree;
  • live path-resolution timing under desktop and browser workloads;
  • polkit authorization and service restart from RootGuardPage;
  • service containment on each supported init system;
  • boot, package upgrade and Anti-Ransomware coexistence tests before immediate protection is enabled in production.

2.5.6 desktop incident triage

The 2.5.6 source keeps the 2.5.4/2.5.5 production emission filter, but separates what is recorded from what interrupts the desktop user. Global privilege metadata is classified as Telemetry, Observation or Incident. Only direct/high-signal transitions create popup incidents; lower-confidence global events remain visible as observations. Protected-path semantics are unchanged. Xattr events now carry the target inode mode and parses the LSM operation flag so security.capability additions/replacements are promoted only when the target is executable; removals remain observations.

2.5.4 production filtering

The 2.5.4 source narrows global metadata emission to privilege-relevant transitions and adds a UI-side compatibility filter so historical broad-audit records cannot create incident popup storms. Protected-path semantics are unchanged.

2.5.7 adaptive desktop guard

Global metadata remains enabled, but eBPF now samples only a bounded number of high-signal records per execution-domain window and counts destructive permission/ownership storms without emitting one record per operation. The domain combines cgroup with actor/parent executable identity so unrelated desktop processes do not share a cooldown. A threshold crossing emits one RG_REASON_METADATA_BURST record and then observes a kernel cooldown. Explicit protected identities bypass sampling and retain their original block/audit semantics. The GTK layer treats normal global records as observations, limits burst popups, and prioritizes protected/service incidents.

The C++ policy, file-identity and event-classification test suites pass in a daemon/GTK-disabled CMake build. Full eBPF verifier/load and GTK linkage still require a target Linux host with kernel BTF, libbpf/bpftool and gtkmm-4.0.