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

> Witr warns about dangerous Linux capabilities and library injection via environment variables in non-root processes. Secure your systems effectively.

- Repository: [Pranshu Parmar/witr](https://github.com/pranshuparmar/witr)
- Tags: how-to-guide
- Published: 2026-08-09

---

**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`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/internal/source/detect.go) ensures that warning strings are returned in a deterministic order. This reproducibility allows the [`internal/source/warnings_test.go`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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:

```bash

# 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:

```bash

# 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:

```go
// 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`](https://github.com/pranshuparmar/witr/blob/main/internal/source/detect.go).
- **Deterministic output** ensures warning arrays are returned in consistent order, facilitating reliable testing in [`internal/source/warnings_test.go`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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`](https://github.com/pranshuparmar/witr/blob/main/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.