Architecture Diagram
How the system fits together
This visual is meant to show the operating shape of the project at a glance: where input begins, where decisions happen, and what the useful output surface actually is.
Diagram of Sysguard showing Linux tracepoints, a Rust policy engine, YAML rules, and outbound connect enforcement.
Snapshot
What matters most in this project
Challenge
The real challenge was building a useful security monitor while staying precise about scope: Linux-first tracing, a userspace policy engine, and intentionally narrow kernel blocking instead of vague claims about full host prevention.
Result
Sysguard shipped as a public prototype with a clear Linux VM workflow, sample policies, helper scripts, and an enforceable outbound-connect path that makes the project useful for hands-on systems and security experimentation.
Approach
- Implemented Linux tracing for execve, openat, and connect events with eBPF programs that stream structured activity into userspace.
- Built an async Rust policy engine that loads YAML rules, suppresses noisy system events, deduplicates repeats, and emits readable or JSON output.
- Added a first enforcement path for outbound IPv4 connect rules through a cgroup connect4 hook so blocking behavior is explicit and testable.
Architecture
- Kernel-space eBPF programs hook Linux tracepoints, parse syscall arguments, and stream structured events through a RingBuffer.
- An async Rust userspace processor matches incoming events against YAML rules and emits classified outputs with noise suppression and deduplication.
- Optional cgroup-based connect4 enforcement handles a narrow set of outbound IPv4 block rules so monitoring and enforcement stay clearly separated.
Impact
Turned low-level Linux tracing into a repo-ready security tool that classifies runtime activity as ALLOW, LOG, ALERT, or BLOCK without pretending the enforcement surface is broader than it is today.
- Traces process launches, file opens, and outbound network connects on Linux through eBPF instrumentation.
- Applies YAML policies to classify activity as ALLOW, LOG, ALERT, or BLOCK with optional machine-readable JSON output.
- Supports kernel-level blocking for a subset of exact IPv4 connect rules through optional cgroup enforcement.
Tradeoffs and Decisions
- Kept platform support honest by treating Linux as the primary target and macOS as a fallback process-polling path for development only.
- Limited kernel blocking to a subset of outbound connect rules instead of overstating enforcement for execve and openat.
- Invested in helper scripts, sample policies, and readable output so the prototype is easier to build, test, and explain from a fresh VM.
Stack