Security Architecture

LinuxGuard is designed with security as a foundational principle. The agent follows a zero-trust, least-privilege model to ensure the monitoring solution does not become a security risk to your infrastructure.

This document explains LinuxGuard's security architecture, covering privilege requirements, eBPF-based monitoring, and the protections that keep your systems safe.

Privilege Model

LinuxGuard separates installation-time privileges from runtime privileges. Root access is required only during installation; normal operation runs as an unprivileged user.

Installation (Root Required)

Root or sudo access is required during installation for:

• Creating the linuxguard user and group - A dedicated system account for running the agent

• Installing files to system directories - Binaries in /usr/bin/, configuration in /etc/linuxguard/

• Registering the systemd service - Adding the service unit file and enabling automatic startup

• Setting up audit integration - Configuring audit rules and granting audit log access

• Granting auth log access - Setting ACLs on authentication logs so the agent can collect login events without root

After installation completes, root access is no longer required for normal operation.

Runtime (Non-Root)

The LinuxGuard agent runs as the unprivileged linuxguard user:

• No system file modification - Cannot alter files in /etc/, /usr/, or other system directories

• Read-only monitoring - Observes system activity without changing it

• Isolated directories - All writes limited to agent-specific locations (/var/lib/linuxguard/, /var/log/linuxguard/)

• No login shell - The linuxguard account cannot be used for interactive access

This separation ensures that even if the agent were compromised, the attacker would have no ability to modify the system or escalate privileges.

Response Executor Privilege Model

When active response is enabled, LinuxGuard deploys a second binary — the response executor (/usr/bin/linuxguard-response-executor) — that runs as a separate, privilege-separated service alongside the monitoring agent.

Executor vs Agent

The monitoring agent and the response executor are distinct binaries with distinct privilege models:

Component	Binary	Runtime User	Purpose
Monitoring agent	linuxguard-agent	linuxguard (non-root)	Collect telemetry and send events to the console
Response executor	linuxguard-response-executor	root	Execute containment actions on demand

The monitoring agent's privilege model — described in the sections above — is unchanged by the presence of the executor.

Why the Executor Runs as Root

The four containment actions require root privileges: usermod, loginctl terminate-user, writes to /etc/sudoers.d/, and writes to /home/*/.ssh/authorized_keys require effective root UID. Linux capabilities are not sufficient for these operations.

The executor runs as root because the containment actions require it — not as a general escalation. Its write access is restricted by systemd to four specific paths:

• /etc/sudoers.d — for the revoke sudo action

• /home — for the disable SSH key action

• /run/linuxguard — for the IPC socket

• /var/log/linuxguard — for the executor audit log

Privilege Separation

The executor does not run as a long-running privileged process. It listens on a Unix domain socket (/run/linuxguard/) and executes operations on demand when the monitoring agent sends a validated command.

Communication between the monitoring agent and the executor uses SO_PEERCRED authentication on the Unix socket — only the linuxguard user (the monitoring agent's operating user) can call the executor. All other callers are rejected at the socket level.

Executor Audit Log

Every containment action executed by the response executor is recorded to /var/log/linuxguard/executor.log as structured JSON. Entries are append-only. This log is separate from the command audit trail in the console and provides a local host-level record of all response operations.

Note: The response executor service is installed only when the active response package is installed. Systems without the active response package run only the monitoring agent, with no root-privileged component present.

See Active Response for the full safety model, playbook configuration, and containment action documentation.

eBPF Architecture

LinuxGuard uses eBPF (extended Berkeley Packet Filter) for kernel-level monitoring. Unlike traditional kernel modules, eBPF programs run in a sandboxed environment with built-in safety guarantees.

Why eBPF

Traditional security agents often use kernel modules to gain visibility into system activity. Kernel modules operate with full kernel privileges, which means a bug in the module can crash the entire system.

LinuxGuard uses eBPF instead, which provides equivalent visibility with stronger safety guarantees:

Approach	Risk if Bug	Crash Recovery	Verification
Kernel module	Kernel panic, system crash	Reboot required	None before load
eBPF program	Program rejected or terminated	Automatic, no reboot	Built-in verifier

eBPF programs are verified by the kernel before they run. If a program contains unsafe operations, the kernel rejects it entirely rather than allowing it to execute.

Loader/Runtime Architecture

LinuxGuard uses a split architecture that separates privileged and unprivileged operations:

1. Loader process - Loads eBPF programs into the kernel. This component requires elevated capabilities (CAP_BPF) to attach monitoring programs to kernel hooks. The loader runs briefly during startup, then exits. eBPF probes automatically reload when the agent binary changes, eliminating the need for manual daemon restarts during updates.

2. Runtime process - Processes events in userspace. This component runs continuously as the unprivileged linuxguard user, receiving events from the kernel and transmitting them to the LinuxGuard console.

This separation limits the code running with elevated capabilities to the minimal loader component. The long-running runtime process operates without elevated privileges.

Safety Guarantees

The Linux kernel's eBPF verifier ensures all LinuxGuard eBPF programs meet strict safety requirements:

• Memory safety - Cannot access arbitrary kernel memory; limited to designated data structures

• Termination - Must complete execution (no infinite loops allowed)

• Kernel stability - Cannot destabilize the kernel or cause a panic

• Spectre hardening - Protected against speculative execution attacks

If verification fails for any reason, the program is rejected and never runs. This is fundamentally different from kernel modules, which can execute arbitrary code with full kernel privileges.

LoginUID Capture

LinuxGuard captures the original login user identity (LoginUID) for all security events. LoginUID survives privilege escalation via sudo or su, enabling non-repudiation for privileged actions.

Why it matters:

When a user runs sudo command, the effective user changes to root, but the LoginUID remains the original user. This allows LinuxGuard to attribute actions to the actual person responsible, even when sudo is involved.

Example attribution:

A file event shows ubuntu (sudo -> root) indicating:

• Original login user: ubuntu

• Effective user after sudo: root

This is critical for security investigations: distinguishing "root logged in directly" from "user X used sudo to become root" provides accountability for privileged actions.

The agent captures LoginUID from the kernel via eBPF probes on execve, openat, and connect syscalls. This kernel-level capture eliminates race conditions where short-lived processes exit before userspace can query /proc.

Note: Kernel 5.5 or later is required for full eBPF userspace argument reads. On older kernels (4.18-5.4), LoginUID capture may have reduced reliability.

See Glossary for the LoginUID definition.

eBPF File Access Monitoring

LinuxGuard uses eBPF to trace openat syscalls at the kernel level, providing real-time visibility into file read and write access across monitored paths.

How it works:

1. eBPF probes attach to the openat syscall entry point

2. Each file open operation is captured with: file path, process ID, user ID, command name, and open flags (read/write intent)

3. Write events are correlated with filesystem change notifications (fsnotify) to provide high-confidence process attribution

4. Read events enable exfiltration detection by identifying processes reading monitored files

Attribution confidence levels:

Level	Source	When Used
HIGH	eBPF openat tracing	eBPF probe successfully captures process context at syscall time
MEDIUM	/proc lookup	eBPF event received but supplemented with /proc/[pid] data
LOW	Fallback	Process exited before attribution could be completed

eBPF-based attribution provides the highest confidence because it captures process information at the kernel level, before the process can exit or change state.

See Console Overview for how attribution levels appear in the File Monitoring page, and Glossary for related terms.

Configuration File Write Detection

LinuxGuard detects writes to security-critical configuration files using eBPF-based monitoring. When a process opens a monitored configuration file with write intent, the agent generates a security signal with full process attribution.

Monitored files:

Category	Files
Privilege escalation	/etc/sudoers, /etc/sudoers.d/*
Authentication	/etc/ssh/sshd_config, /etc/pam.d/*, /etc/security/*
User/group management	/etc/passwd, /etc/group, /etc/shadow, /etc/gshadow
SSH access	~/.ssh/authorized_keys (all users)

Why it matters:

Unauthorized modifications to these files are common persistence and escalation techniques:

• Adding a sudoers rule grants an attacker root access

• Modifying sshd_config can weaken SSH security

• Adding entries to authorized_keys creates a backdoor

• Changing /etc/passwd or /etc/shadow can create unauthorized accounts

Each signal includes the process name, full command line, working directory, and LoginUID for complete attribution of who made the change.

Important: Configuration File Write Detection may not be visible until enabled by your LinuxGuard administrator. Contact support to enable this feature.

See Glossary for the Configuration File Write Detection definition.

Linux Capabilities

Linux capabilities split root privileges into discrete units. LinuxGuard uses only the specific capabilities needed for monitoring, avoiding broad privileges like CAP_SYS_ADMIN.

Capabilities Used

Capability	Purpose	Why Needed
CAP_BPF	Load eBPF programs	Attach monitoring programs to kernel hooks
CAP_PERFMON	Performance monitoring	Access performance counters for security monitoring
CAP_DAC_READ_SEARCH	Read file permissions bypass	Read authentication logs and scan files for security analysis regardless of ownership
CAP_AUDIT_READ	Read audit logs	Access kernel audit events for security monitoring

Capabilities NOT Used

LinuxGuard deliberately avoids broad capabilities:

• CAP_SYS_ADMIN - Full administrative access; too broad for monitoring purposes

• CAP_NET_ADMIN - Network configuration; not needed for read-only monitoring

• CAP_SYS_PTRACE - Process tracing; not needed for eBPF-based monitoring

This capability model follows the principle of least privilege: the agent has only the specific capabilities required for its monitoring function, nothing more.

Systemd Hardening

LinuxGuard's systemd service includes hardening directives that restrict what the agent can do, even if compromised. These directives provide defense-in-depth beyond the agent's own security model.

Hardening Directives

Directive	Protection	What It Prevents
ProtectSystem=strict	Read-only filesystem	Agent cannot modify system files
PrivateTmp=true	Isolated /tmp	Cannot access other processes' temp files
ProtectHome=true	No home directory access	Cannot access user home directories
NoNewPrivileges=true	No privilege escalation	Cannot gain additional capabilities
ProtectKernelTunables=true	Read-only /proc and /sys	Cannot modify kernel parameters

Verify Hardening

You can inspect the actual hardening configuration:

# View the complete service configuration
systemctl cat linuxguard-agent

# Check systemd security score (lower is better)
systemd-analyze security linuxguard-agent

The systemd-analyze security command scores services based on their hardening. A score under 5.0 indicates a well-hardened service.

Package Integrity

RPM Package Signing

LinuxGuard signs all RPM packages with a GPG key. When DNF or YUM installs or updates the linuxguard-agent package, the package manager verifies the signature against the LinuxGuard GPG key before installing any files.

What this provides:

• Origin verification — The package was built and signed by LinuxGuard, not a third party

• Tamper detection — Any modification to the package after signing invalidates the signature, and the package manager rejects installation

Key details:

The LinuxGuard GPG public key is imported to the host at repository setup time:

• Key location on host: /etc/pki/rpm-gpg/RPM-GPG-KEY-linuxguard

• Key source URL: https://packages.linuxguard.io/dnf/packages/repodata/RPM-GPG-KEY-linuxguard

• Repository setting: gpgcheck=1 in the LinuxGuard DNF/YUM repository configuration

With gpgcheck=1, DNF and YUM will refuse to install any package whose signature does not verify against the imported key. This applies to every install and every update.

Note: GPG signature verification applies to RPM packages (RedHat, CentOS, SUSE distributions). See the RedHat / CentOS installation guide for repository setup instructions.

What LinuxGuard Does NOT Do

LinuxGuard is designed with explicit limitations. Understanding what the agent deliberately does not do is as important as understanding what it does.

Does not modify system files

• No changes to /etc/, /usr/, or other system directories

• All writes limited to /var/lib/linuxguard/ and /var/log/linuxguard/

• Configuration changes require administrator action, not agent action

Does not install kernel modules

• Uses eBPF, not loadable kernel modules

• Cannot crash the kernel or cause kernel panics

• Does not require kernel rebuilds or module signing

Does not require persistent root access

• Root/sudo used only during installation

• Runtime uses the unprivileged linuxguard user

• No sudo rules or SUID binaries required

Does not intercept or modify network traffic

• Read-only network monitoring

• No proxy functionality

• No firewall rules or traffic modification

• No man-in-the-middle capabilities

Does not collect or transmit without consent

• Only enrolled agents send data to the LinuxGuard console

• Unenrollment stops all data transmission immediately

• No background data collection before enrollment

Does not act without explicit operator configuration

• Response actions (account lock, session termination, SSH key disable, sudo revocation) only fire when a playbook is explicitly created, scoped to specific server groups, and enabled by an operator

• No automated response occurs on any server until a playbook targeting that server's group is enabled

• The monitoring agent collects and reports telemetry at all times; automated response is a separate, explicitly-configured capability that is disabled by default

How LinuxGuard Compares

Security teams evaluating LinuxGuard often compare it to other agent architectures. This section provides factual comparison across three categories: kernel module agents, userspace-only agents, and cloud-native security tools.

vs Kernel Module Agents

Traditional security agents use loadable kernel modules for deep visibility into system activity. While effective, this approach carries inherent risks.

Aspect	Kernel Module Agent	LinuxGuard (eBPF)
Kernel crash risk	Module bugs can panic kernel	eBPF programs cannot crash kernel
Kernel compatibility	Requires module per kernel version	Portable across kernels 4.18+
Update impact	May require reboot	Hot-reload without reboot
Code verification	None before load	Built-in eBPF verifier

LinuxGuard's eBPF approach provides equivalent visibility with the kernel's built-in safety guarantees. If an eBPF program contains an error, the kernel rejects it before execution rather than risking system instability.

vs Userspace-Only Agents

Some security agents operate entirely in userspace, avoiding kernel integration to minimize risk.

Aspect	Userspace-Only Agent	LinuxGuard (eBPF)
Kernel visibility	Limited to /proc, logs	Direct kernel event stream
Detection latency	Polling-based delays	Real-time event capture
Resource overhead	Higher CPU for polling	Efficient in-kernel filtering

Userspace-only agents cannot see kernel events as they happen. They rely on polling system files or parsing logs, which introduces delays and increases CPU usage. LinuxGuard's eBPF programs run inside the kernel, capturing events at the source with minimal overhead.

vs Cloud-Native Security Tools

Container-focused security tools (like those using eBPF for Kubernetes security) share many of eBPF's benefits but target different use cases.

Aspect	Cloud-Native Tools	LinuxGuard
Primary focus	Container/K8s security	Host-level security
Deployment	DaemonSet/Sidecar	System package
Scope	Pod-centric policies	Server-centric monitoring
Integration	K8s API, admission control	Audit system, systemd

Cloud-native tools excel at container workload protection and Kubernetes policy enforcement. LinuxGuard focuses on host-level security monitoring across physical servers, virtual machines, and the underlying infrastructure that containers run on.

Security Q&A

Common questions from security teams evaluating LinuxGuard.

Does LinuxGuard need root?

For installation: Yes. Creating the linuxguard user, installing files to system directories, and registering the systemd service requires root or sudo access.

For runtime: No. The agent runs as the unprivileged linuxguard user. Root access is not required for normal operation after installation.

What kernel access does it have?

LinuxGuard uses eBPF to monitor kernel events. eBPF programs are:

• Verified by the kernel before loading

• Unable to access arbitrary kernel memory

• Unable to modify kernel state

• Running in a sandboxed environment

The agent observes kernel activity but cannot change kernel behavior.

Can the agent be compromised?

Any software can theoretically be compromised. LinuxGuard employs defense-in-depth to limit the impact of a potential compromise:

1. Least privilege - Runs as non-root with minimal Linux capabilities

2. Systemd hardening - NoNewPrivileges, ProtectSystem, PrivateTmp restrict what the process can do

3. eBPF sandboxing - Even eBPF code is verified and sandboxed by the kernel

4. Network encryption - All API communication uses HTTPS

5. Automatic updates - Security patches delivered via package manager

If the agent process were compromised, the attacker would have:

• Access limited to linuxguard-owned directories (/var/lib/linuxguard/, /var/log/linuxguard/)

• No ability to escalate privileges (NoNewPrivileges=true)

• Read-only access to system files (ProtectSystem=strict)

• No network configuration capabilities

What data does LinuxGuard collect?

LinuxGuard collects security-relevant telemetry:

• Process execution events (what programs run, who runs them)

• File access events (what files are read, written, modified) via eBPF-based file monitoring

• Network connection events (what connections are established)

• Authentication events from syslog, journald, and utmp/wtmp/btmp logs (login successes, failures, brute force detection)

• Audit log events (kernel audit subsystem data)

• System resource metrics (CPU, memory, disk, network utilization via sysstat)

• User behavior baselines for anomaly detection

LinuxGuard does not collect:

• File contents (only metadata: path, timestamps, hashes, permissions)

• Keystrokes or screen captures

• Personal data beyond process metadata

• Data before enrollment (agent must be enrolled to transmit)

Verification Commands

Verify LinuxGuard's security configuration yourself. Each command includes expected output.

Check agent runs as non-root

ps aux | grep linuxguard-agent

Expected: Process shows linuxguard user in the first column, not root.

View systemd hardening configuration

systemctl cat linuxguard-agent

Expected: Shows hardening directives including ProtectSystem=strict, NoNewPrivileges=true, PrivateTmp=true.

Check systemd security score

systemd-analyze security linuxguard-agent

Expected: Overall exposure level under 5.0 indicates a well-hardened service. Lower scores mean more restrictions are in place.

Verify file permissions

ls -la /etc/linuxguard /var/lib/linuxguard

Expected: Directories owned by linuxguard:linuxguard with restrictive permissions (750 or similar).

Verify agent user has no login shell

getent passwd linuxguard

Expected: Shell field shows /usr/sbin/nologin or /bin/false, preventing interactive login.

Check agent user exists with correct properties

id linuxguard

Expected: Shows uid, gid, and groups for the linuxguard system account.

Directory Structure and Permissions

The installer creates a secure directory structure with appropriate ownership and permissions:

Agent-Owned Directories (read-write access):

• /etc/linuxguard/ - Agent configuration files

• /var/lib/linuxguard/ - Agent state and data files

• /var/run/linuxguard/ - Runtime files and process information

• /var/log/linuxguard/ - Agent log files

All agent-owned directories are:

• Owned by the linuxguard user and group

• Protected with restrictive permissions (750 or 755)

• Isolated from other system components

System Component Access (read-only access):

• The agent requires read-only access to certain system components for monitoring purposes

• This includes system logs, configuration files, and audit data

• Read access is granted only where necessary for security monitoring functionality

• The agent cannot modify any system files or configurations

Dedicated User Account

The installer creates a dedicated linuxguard user and group specifically for running the agent. This user account:

• Has no login shell (cannot be used for interactive access)

• Is a system account (not intended for human users)

• Operates with minimal system privileges

• Is isolated from other system processes and users

Audit System Integration

LinuxGuard integrates with the Linux audit system (auditd) to provide comprehensive security monitoring. The installer:

• Installs audit rules that define what events to monitor

• Creates a dedicated audit group (linuxguard-audit) for accessing audit logs

• Configures the audit daemon to allow the agent to read audit logs securely

• Ensures audit logs are accessible without requiring root privileges

This integration allows LinuxGuard to monitor system calls, file access, network activity, and other security-relevant events without running with elevated privileges.

Service Management

The agent runs as a system service under the linuxguard user account. The installer:

• Registers the agent as a system service (systemd or OpenRC, depending on your distribution)

• Configures the service to start automatically on system boot

• Ensures the service runs with the correct user permissions

• Provides standard service management capabilities (start, stop, restart, status)

Runtime Security

Once installed and running, the LinuxGuard agent:

• Runs as non-root: All agent processes execute under the linuxguard user account

• Read-only monitoring: Monitors system activity with read-only access to system components

• Isolated data: Stores all agent data in dedicated directories with restricted access

• Secure communication: All communication with the LinuxGuard console uses encrypted HTTPS connections

• No system modifications: The agent never modifies system files, configurations, or other components outside its own directories

Security Benefits

This security model provides several key benefits:

1. Reduced Attack Surface: By running without root privileges, the agent cannot be used to escalate privileges or compromise the system

2. Compliance: The least-privilege model helps meet security compliance requirements

3. Isolation: Agent processes and data are isolated from other system components

4. Transparency: Clear separation between agent operations and system operations

5. Auditability: The agent's own operations can be monitored and audited like any other system process

Best Practices

When deploying LinuxGuard in your environment:

• Review permissions: Periodically review the agent's file permissions to ensure they remain restrictive

• Monitor agent activity: Use your existing security monitoring to track agent behavior

• Keep updated: Regularly update the agent to receive security patches and improvements

• Network security: Ensure network policies allow the agent to communicate with api.linuxguard.io over HTTPS

• Audit logs: Review agent logs regularly to ensure normal operation

---

Related: Installation | Console Overview | Glossary | Troubleshooting