GTK4/gtkmm integration

RootGuardPage is a non-privileged Gtk::Box located directly in src/rootguard. It does not load BPF programs or edit protected files itself. Privileged service, policy and incident actions are delegated through the installed helpers using pkexec; JSONL reads and command execution occur in the client worker thread.

Compact page structure

The page uses a Gtk::Stack and Gtk::StackSwitcher so it does not force the main BastionGuard window to grow vertically:

• Overview — service state, immediate-blocking switch, scope warning and service controls.
• Incidents — current observations and blocked protected changes.
• Events — terminal-style JSONL summary with an optional trusted-event filter.
• Application rules — nested tabs for routine trusted applications, privilege-trusted executables and denied executables.

Immediate-blocking scope

The information control beside the switch explains that immediate blocking is for protected system identities and service definitions. User home directories remain audit-only by default and are enforced by BastionGuard Anti-Ransomware. The helper writes global_metadata_action = audit and block_user_home = false when the switch is changed from the GUI.

Application rules

Routine desktop and browser applications may remain in [trusted-applications] for compatibility with informational global events. Production filtering now drops ordinary chmod/chown/ACL traffic before it reaches the UI. High-confidence privilege metadata is never downgraded merely because the actor is a desktop application. This list never grants privilege-transition trust and never bypasses protected-path enforcement.

The other editors map to [trusted-executables] and [denied-executables]. The UI presents the latter as Blocked while stating that it is a privilege-transition policy, not a general application-launch blacklist. A convenience button adds only installed known desktop/browser executables to the trusted-applications editor for review before saving.

Saving rules performs these steps:

1. validate absolute paths and conflicts;
2. atomically rewrite the three policy sections while preserving ownership and permissions;
3. validate the complete policy;
4. restart RootGuard;
5. refresh the page from the daemon's policy view.

Event transparency

The page shows the event path, how that path was resolved, device/inode identity when applicable, the actor executable and PID. A basename-only event is labelled as such and Restore/Quarantine are disabled. Audit notifications contain only Acknowledge; trusted events generate no popup.

MainWindow

#include "rootguard/RootGuardPage.hpp"
 
rootguard_page_ = Gtk::make_managed<RootGuardPage>();
stack_.add(*rootguard_page_, "rootguard");

Native CMake integration

After the main add_executable(BastionGuard ...):

add_subdirectory(
    "${CMAKE_SOURCE_DIR}/src/rootguard"
    "${CMAKE_BINARY_DIR}/bastionguard-rootguard-build"
)
 
target_link_libraries(BastionGuard PRIVATE BastionGuard::RootGuardUI)

No ExternalProject, Meson stage or second installation pass is used.