RootGuard incident response

Immediate blocking

The GTK switch does not perform security enforcement itself. It atomically updates the installed policy and reloads the daemon. In the enabled state the kernel BPF LSM programs return -EPERM for protected metadata operations. This design keeps enforcement active when BastionGuard is minimized or closed.

Incident states

The page reads the JSONL event stream and displays the newest unresolved event for each protected path. A later file-restored, file-quarantined, or integrity-restored event closes the older incident in the page.

Restore

Restore is allowed only when the current path still has the baseline device and inode. The privileged helper opens it with O_NOFOLLOW, verifies it with fstat, and applies owner/group and mode using fchown and fchmod.

For a systemd unit, restoration also removes its runtime mask. RootGuard does not restart the service automatically.

Remove

Remove is implemented as quarantine. The helper first stops a recognized service, then atomically renames the file into:

/var/lib/bastionguard/rootguard/quarantine

The quarantined file receives mode 0000, and a sidecar manifest records its original path, mode, owner, device, and inode. The GUI passes the protected device/inode identity to the helper. A replaced OpenRC/SysV script is never executed as root during quarantine; the page reports that its process may need manual containment.

Missing or replaced files

RootGuard deliberately does not copy protected file contents. Protected paths can include /etc/shadow, PAM configuration, and other sensitive data for which a broad userspace backup would create a second high-value secret store. For a missing or replaced inode, the page disables metadata restoration. Restore content through the package manager, an authenticated backup, or configuration management; quarantine a replacement before restoration.

System services

The daemon recognizes:

• systemd unit files and drop-ins under /etc/systemd/system, /usr/lib/systemd/system, and /lib/systemd/system;
• OpenRC/SysV scripts under /etc/init.d;
• OpenRC service configuration under /etc/conf.d;
• dinit service definitions under /etc/dinit.d and /usr/lib/dinit.d.

The response runs in the daemon, not the GUI, and therefore remains active when no desktop session is available.

Init-script safety

A denied LSM event guarantees that the OpenRC/SysV script on disk was not changed, so RootGuard can use the normal stop command. For an after-the-fact integrity drift, RootGuard does not execute the affected OpenRC/SysV script as root. It reports a service-block failure and leaves manual containment to the administrator. systemd and dinit can stop the already loaded service without executing the changed definition.