Directories | |
| bpf | |
| demo | |
| docs | |
| include | |
| src | |
| tests | |
Files | |
| RootGuardClient.cpp | |
| RootGuardClient.hpp | |
| RootGuardEvent.cpp | |
| RootGuardEvent.hpp | |
| RootGuardPage.cpp | |
| RootGuardPage.hpp | |
RootGuard is BastionGuard's eBPF LSM privilege-escalation and filesystem metadata monitor. It filters global metadata activity down to privilege-relevant transitions and performs complete baseline monitoring on explicitly protected system identities, where changes can be denied before they are committed.
RootGuard deliberately separates four concepts:
The default policy keeps user home directories audit-only even when immediate blocking is enabled. BastionGuard Anti-Ransomware remains responsible for user-data enforcement. Immediate blocking applies to protected system paths, including service definitions; blocked service-definition changes can trigger native service containment.
RootGuardPage uses compact tabs:
The Overview tab contains an information popover explaining the system/home scope. The Application rules tab contains nested editors for trusted applications, privilege-trusted executables and blocked/denied executables. A convenience button adds only installed known desktop/browser executables for review. Saving is explicit, policy validation is atomic, administrator authentication is used, and RootGuard is restarted only after a successful save.
Protected-path audit notifications are acknowledgement-only. Individual global metadata records are observations and never open a popup. A high-volume destructive permission pattern is aggregated by eBPF into one metadata-burst incident; the GTK client caps burst interruptions to one every 15 minutes while keeping the complete sampled history available for investigation.
For chmod/chown, the BPF LSM path hook captures the mount-aware target path before inode_setattr; Linux 6.12 and newer use the optional bpf_path_d_path kfunc. Protected baselines, open process descriptors and the process working directory remain additional resolution sources.
The executable identity is captured at exec time and copied into later events, so short-lived actors remain identifiable after /proc/<pid> disappears. Notifications show PID, TGID, PPID, parent process, actor and parent executable, EUID, target path/directory and device/inode identities. If an operation reaches only an inode hook and no exact mount-aware path is available, RootGuard reports that limitation and never invents a directory.
[trusted-applications] is intentionally separate from [trusted-executables].
The module belongs at src/rootguard and is included directly:
The build supports systemd, OpenRC, dinit and SysV init. Set ROOTGUARD_INIT_SYSTEM explicitly when producing a distribution package.
The installed rootguard.conf is preserved across later cmake --install runs. The packaged reference policy is installed as rootguard.conf.default.