Witr Warnings for Dangerous Capabilities and Library Injection: A Complete Guide

Witr emits safety-oriented warnings when it detects dangerous Linux capabilities (like CAP_SYS_ADMIN) in non-root processes or library injection vectors (like LD_PRELOAD and DYLD_INSERT_LIBRARIES) via environment variables.

The pranshuparmar/witr repository provides process inspection capabilities that alert operators to potentially unsafe runtime configurations. By analyzing process state and environment variables, witr surfaces deterministic warning strings that help identify privilege escalation risks and dynamic library injection attempts. These warnings are generated by the Warnings function in internal/source/detect.go and formatted for both human-readable and JSON outputs.

How Witr Detects Dangerous Linux Capabilities

Witr inspects process privilege contexts by reading kernel capability sets from the /proc/<pid>/status filesystem. When a non-root process holds specific privileged capabilities, the tool flags these as security concerns.

Capability Inspection via /proc Filesystem

On Linux systems, witr reads the CapEff (effective capabilities) field from /proc/<pid>/status to decode the capability bitmap. The detection logic translates these bitmap values into human-readable capability names and compares them against a hard-coded list of dangerous privileges.

The following capabilities trigger warnings when present in non-root processes:

• CAP_SYS_ADMIN – Allows a range of administrative operations
• CAP_DAC_OVERRIDE – Bypasses file read/write/execute permission checks
• CAP_NET_RAW – Permits raw socket access for network packet manipulation

When detected, witr generates the warning: Process has dangerous Linux capabilities (CAP_SYS_ADMIN, CAP_DAC_OVERRIDE).

Deterministic Warning Output

The capability check implementation around line 163 of internal/source/detect.go ensures that warning strings are returned in a deterministic order. This reproducibility allows the internal/source/warnings_test.go suite to validate specific warning sequences consistently across test runs.

Library Injection Detection in Witr

Witr scans process environments for variables that enable runtime shared object injection, flagging both Linux and macOS dynamic linker configurations that could facilitate code injection attacks.

Linux Environment Variables (LD_PRELOAD, LD_LIBRARY_PATH)

The detection logic maintains a static list called envVarRules (defined at line 93 of internal/source/detect.go) that maps suspicious environment variables to warning messages. For Linux systems, witr specifically monitors:

• LD_PRELOAD – Forces loading of specified shared objects before all others
• LD_LIBRARY_PATH – Alters the shared library search path

When LD_PRELOAD is detected, witr emits: Process sets LD_PRELOAD (potential library injection).

macOS Dynamic Linker Variables (DYLD_*)

On macOS systems, witr extends detection to Apple's dynamic linker environment variables:

• DYLD_INSERT_LIBRARIES
• DYLD_FORCE_FLAT_NAMESPACE
• DYLD_LIBRARY_PATH

The warning format for macOS variables follows the pattern: Process sets DYLD_* variables (potential library injection): DYLD_INSERT_LIBRARIES.

The envVarRules Mapping

The envVarRules structure in internal/source/detect.go provides a maintainable mapping between raw environment variable names and user-friendly warning text. This abstraction allows the Warnings function to iterate through process environments efficiently while preserving consistent messaging across platforms.

Implementation Details in internal/source/detect.go

The core warning generation logic resides in the Warnings function within internal/source/detect.go. This function:

1. Accepts a Process struct containing PID, environment variables, and capability lists
2. Iterates through environment variables against envVarRules
3. Validates Linux capabilities against the dangerous capabilities whitelist
4. Returns a slice of warning strings in deterministic order

The internal/output/standard.go file handles formatting these warnings for CLI display, while the JSON output mode (--json flag) structures warnings as an array for programmatic processing.

Viewing Witr Warnings: CLI Examples

To inspect warnings for a specific process using its PID:

# Show only warnings for a given process (PID 1234)

$ witr --pid 1234 --warnings
Warnings:
  • Process sets LD_PRELOAD (potential library injection)
  • Process has dangerous Linux capabilities (CAP_SYS_ADMIN, CAP_DAC_OVERRIDE)

For automation and integration with monitoring systems, use the JSON output format:

# Use the JSON output to programmatically inspect warnings

$ witr nginx --json | jq '.warnings'
[
  "Process sets LD_PRELOAD (potential library injection)",
  "Process has dangerous Linux capabilities (CAP_SYS_ADMIN, CAP_DAC_OVERRIDE)"
]

The following Go snippet demonstrates the warning detection API as implemented in the test suite:

// Minimal Go snippet that reproduces the warning detection (borrowed from the test suite)
p := internal.Process{
    PID:  5678,
    Envs: []string{"LD_PRELOAD=/tmp/mylib.so"},
    Caps: []string{"CAP_SYS_ADMIN"},
}
warnings := internal.Warnings(p, 0)
fmt.Println(warnings)
// Output:
// [Process sets LD_PRELOAD (potential library injection) Process has dangerous Linux capabilities (CAP_SYS_ADMIN)]

Summary

• Dangerous capabilities detection reads CapEff from /proc/<pid>/status and flags non-root processes holding CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, or similar privileged capabilities.
• Library injection warnings scan for LD_PRELOAD, LD_LIBRARY_PATH (Linux), and DYLD_INSERT_LIBRARIES (macOS) via the envVarRules mapping in internal/source/detect.go.
• Deterministic output ensures warning arrays are returned in consistent order, facilitating reliable testing in internal/source/warnings_test.go.
• Multiple output formats support both human-readable CLI warnings and structured JSON arrays for programmatic consumption.

Frequently Asked Questions

What specific Linux capabilities does witr consider dangerous?

Witr flags capabilities including CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, and CAP_NET_RAW when they appear in non-root processes. The complete list is hard-coded in the capability checking logic around line 163 of internal/source/detect.go, focusing on privileges that allow system administration, permission bypass, or raw network access.

How does witr detect potential library injection on macOS?

Witr scans process environments for macOS-specific dynamic linker variables including DYLD_INSERT_LIBRARIES, DYLD_FORCE_FLAT_NAMESPACE, and DYLD_LIBRARY_PATH. When detected, it emits warnings identifying the specific variables set, formatted as Process sets DYLD_* variables (potential library injection): [variable_name].

Can witr warnings be consumed programmatically?

Yes, witr supports JSON output via the --json flag, which structures warnings as a string array accessible through the .warnings key. This allows integration with monitoring systems, CI/CD pipelines, and security automation tools that need to parse warning data without regex extraction from human-readable text.

Where is the warning generation logic tested?

The warning detection logic is validated in internal/source/warnings_test.go, which ensures that both capability-based and environment-variable-based warnings are emitted correctly. The test suite verifies deterministic ordering of warning strings and correct identification of dangerous configurations across different process states.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}