NETCAP:(8)

✨ NETCAP:(8) ✨

System Administration Utilities 🎀 NETCAP:(8)

ok bestie, sit down, grab a strawberry 🍓 — we're reading the netcap page together and it's genuinely so good.

---

🌸 NAME 🌸

netcap — a program to review network capability posture 💅

---

✨ SYNOPSIS ✨

netcap [--advanced [--interface IFACE ] [--list-interfaces] [--json]
[--no-color]]

---

💖 DESCRIPTION 💖

netcap is a program that prints out a report of process capabilities. Iconic behaviour, no notes.

By default it runs in its historical filtered mode: if an application is using tcp, udp, raw, or packet family sockets AND has any capabilities, it will be in the report. That's the vibe check right there.

If the process has partial capabilities, it gets further examined to see if it has an open-ended bounding set. If this is found to be true, a '+' symbol is added. And if the process has ambient capabilities, a '@' symbol is added. 🫶

Heads up though — Bluetooth sockets are NOT discovered in this historical filtered mode. Use --advanced when Bluetooth listener discovery is needed. Not me forgetting that and being confused for twenty minutes 🙈

With --advanced, netcap switches to bind/listener inventory mode for the current network namespace. In this mode, reachable binds/listeners are reported regardless of whether the owning process has capabilities — including Bluetooth listeners that are not visible in classic mode. main character energy honestly.

Some directories in the /proc file system are readonly by root. The program will try to access and report what it can. Full output normally requires root, or a combination of CAP_DAC_READ_SEARCH (to read other processes' /proc/<pid>/fd) and CAP_NET_ADMIN (for NETLINK_SOCK_DIAG queries that cover SCTP, DCCP, and, when built with VSOCK support, VSOCK).

Without these permissions, the report is partial; missing sock_diag-derived protocols are omitted without an explicit warning. Lowkey rude of it but okay bestie, that's the deal. 💀

---

🎀 OPTIONS 🎀

• --advanced — Enable the posture/tree view. This mode inventories reachable binds in the current network namespace and shows per-process capabilities, defenses, and flags. The glow-up option fr fr.
• --interface IFACE — With --advanced, limit the report to the named interface. Output format and wrapping are unchanged; only interface-scoped rows for that interface are kept. This also filters --list-interfaces output to the named interface. So focused, so slay. 💅
• --list-interfaces — With --advanced, list the current network namespace interface names instead of the exposure tree. Just the names, no drama.
• --json — With --advanced, emit machine-readable JSON instead of the tree view. When combined with --list-interfaces, emit machine-readable interface inventory JSON instead of text. For the robots and the scripts 🦋
• --no-color — Suppress colored output. By default, when stdout is a terminal, keywords are colorized by severity to highlight problems, cautions, and positive hardening state. (Turning this off is a crime against aesthetics but do what you gotta do.)

---

🌈 ADVANCED MODE 🌈

Advanced mode is an attack-surface and posture inventory for the current network namespace. It is intended for administrators who need a structured view of bind ownership and process hardening state. It's giving security audit, it's giving organized.

With --advanced --list-interfaces, the advanced-mode interface snapshot is rendered directly without enumerating listeners. This is intended as a simple interface enumeration step before later per-interface analysis.

With --advanced --interface IFACE, the same inventory and tree/JSON renderers are used, but only endpoints projected onto that interface are retained. Same renderers, narrower lens, obsessed. ✨

The tree layout is:

Planes -> interface -> protocol -> bind -> port -> process ->
caps/defenses/flags

For VSOCK, the interface/address hierarchy is skipped and rendered as:

Planes -> endpoint -> process -> caps/defenses/flags

For BLUETOOTH, the interface is the HCI adapter (for example hci0). Bluetooth bind nodes are the local controller address or * for wildcard binds.

Planes are grouped as INET (external), INET (loopback), BLUETOOTH, VSOCK, and LINK-LAYER. These names match the tree output exactly, so don't go renaming them, bestie.

The console tree is a causal exposure chain: protocol, then bind address, then port, then owning process. Wildcard binds are printed as *. In tree view, a single 0.0.0.0 or :: listener is expanded onto every non-loopback interface in the current namespace. The same daemon may therefore appear under multiple interfaces, reflecting wildcard-bind reachability. Some endpoints may appear under interface multicast/group when bound to multicast addresses that do not map to a single interface; these represent group-joined sockets rather than point-to-point listeners. Not a glitch, it's reachability 💖

Under each protocol, bind nodes are socket bind addresses (exposure), and port nodes are children of binds.

Each process entry may include a unit field showing the systemd service or scope name, extracted from the process cgroup hierarchy; it is omitted when the process is not managed by systemd. Each process line also includes an optional exe field showing the full executable path read from /proc/<pid>/exe; it is omitted for kernel threads or when the path is unreadable. The kernel Name: field shown as comm is truncated to 15 characters, so exe provides the complete binary path. iykyk 🧚

Socket selection is protocol-specific:

• TCP: LISTEN sockets only.
• UDP/UDPLITE: bound sockets.
• RFCOMM: all owned RFCOMM sockets (state and channel are not exposed by the kernel's proc interface).
• HCI: all bound raw management sockets; semantics differ from port listeners and are analogous to packet sockets.
• SCTP/DCCP: listener sockets only; established flows are not shown. These protocols are discovered via NETLINK_SOCK_DIAG, which requires CAP_NET_ADMIN; without that capability, SCTP and DCCP listeners are silently absent from the report. 💀
• VSOCK: when built with linux/vm_sockets.h, stream LISTEN sockets, plus bound datagram/seqpacket sockets.
• RAW/PACKET: shown as binds; semantics differ from port listeners.

The defenses section is best-effort: no_new_privs and seccomp mode are read from /proc/<pid>/status when available, and the LSM label is read from /proc/<pid>/attr/current when available. runs_as_nonroot is always reported. periodt.

Flags annotate notable conditions:

• wildcard-bind: bind is bound to a wildcard address (for example 0.0.0.0 or ::).
• hypervisor-plane: bind is in the VSOCK communication plane.
• proximity-plane: bind is reachable by any Bluetooth device within radio range. 😳
• ssh-on-vsock-port-22: VSOCK bind uses port 22.
• privileged-caps: process has capabilities considered privileged for attack-surface review (CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_DAC_READ_SEARCH, CAP_NET_ADMIN, and CAP_NET_RAW).

The caps field may include bracketed annotations: [ambient-present] indicates ambient capabilities are set, and [open-ended-bounding] indicates the bounding set is non-empty (the process or its children can potentially gain additional capabilities). 👑

---

🦋 JSON OUTPUT 🦋

When --advanced --json is used, the top-level object contains:

• schema_version (integer).
• planes (array).

Each plane object contains name, optional scope (external or loopback), and either:

• ifaces (INET/LINK-LAYER/BLUETOOTH planes), or
• endpoints (VSOCK plane).

Under ifaces: each interface has name and addrs (array). Each addr object has addr and endpoints (array).

For INET, LINK-LAYER, and BLUETOOTH planes, each endpoint object has label, proto, bind, port, and processes (array). For BLUETOOTH planes, interface names are HCI adapter names (for example hci0); port is 0 for HCI sockets and for RFCOMM sockets whose channel is not exposed by procfs.

For VSOCK planes, endpoint objects use label, vsock_type (socket type string: stream/dgram/seqpacket), cid (source CID or the string ANY), port, and processes; they do not include proto or bind. When built without linux/vm_sockets.h, the VSOCK plane and VSOCK flags are omitted.

Each process object has comm, optional exe, pid, uid, optional unit, caps, ambient_present (boolean), open_ended_bounding (boolean), defenses object, and flags array.

ambient_present and open_ended_bounding are the structured equivalents of the [ambient-present] and [open-ended-bounding] annotations that may appear in the caps text string; both fields are always present in JSON output.

Fields under endpoints/processes/defenses may be omitted when unavailable. When process defenses are present, they include runs_as_nonroot, derived from the real UID (first field of Uid: in /proc/<pid>/status): yes when real uid != 0, no when real uid == 0. A process that started as root and later changed only effective UID via setuid still reports no. 🙈

If a plane has no discovered binds, it appears with an empty list. If a consumer does not receive a given plane, treat it as none found or omitted by the producer.

When --advanced --list-interfaces --json is used, the top-level object contains schema_version (integer) and interfaces (array of interface-name strings).

---

...and bestie, we're not done yet — there's more of this page coming, so don't go anywhere 💜

🔍 INTERPRETATION 🔍

okay bestie, this is where we actually read the output and figure out who's being messy 💅

netcap reports processes that are both network-facing and running with capabilities. The capability set it shows you is the permitted set. Two tiny annotations to watch for:

• a + means the process has an open-ended bounding set
• an @ means the process has ambient capabilities

The colorized tree output exists to prioritize remediation fast, no cap:

• orange highlights problems to fix
• yellow highlights cautionary conditions to review
• green highlights good hardening state
• uncolored output is just neutral context

---

the caps line, aka the receipts

The caps line shows permitted capabilities. And listen, they're tiered:

Orange-tier caps represent severe privilege that is rarely necessary for network-facing daemons. The whole list:

• sys_ptrace
• sys_module
• sys_rawio
• setuid
• setgid
• setpcap
• audit_control

Yellow-tier caps are common but still materially increase attack impact:

• sys_admin
• dac_override
• dac_read_search
• net_admin
• net_raw
• chown
• fowner
• mknod
• sys_chroot

And the two special cases you need to clock:

• caps: (full) means all capabilities are present — that's effectively full root privilege 😭
• caps: (none) is the ideal outcome, the dream, the goal 🎀

ambient caps, the sneaky ones

Ambient capabilities are inherited across execve by child processes (unless constrained by no_new_privs), so their presence on a network daemon is typically a problem. The ambient: line lists the active ambient capabilities. Not me seeing ambient caps on a daemon and immediately spiraling 🙈

[open-ended-bounding], explained

[open-ended-bounding] means the process has not trimmed its bounding set ceiling. This is not active privilege by itself — so don't panic — but it leaves future privilege-acquisition paths open (for example via file capabilities or ambient inheritance). Highkey a future-you problem, so fix it now.

For libcap-ng users, trimming is typically a one-flag change (CAPNG_SELECT_BOUNDS) in existing capability-set calls. With libcap, bounding capabilities are dropped individually. iykyk.

defense fields, the vibe check 🛡️

These summarize exploit-resistance posture:

• no_new_privs: yes — blocks privilege gain through setuid/file-capability exec paths, and is often the highest-value single toggle. Literally the glow-up.
• seccomp: filter — restricts available syscalls (disabled means no syscall filtering at all 👀)
• runs_as_nonroot: yes — indicates non-UID-0 execution

flags, aka reachability & interception context

• wildcard-bind — the daemon listens on every interface
• hypervisor-plane — indicates host/guest boundary exposure (VSOCK)
• proximity-plane — indicates that the bind is reachable by Bluetooth devices within radio range
• reuseport — means another process with the same UID could bind and potentially intercept traffic 😳

protocol nodes, the spicy ones 🌶️

raw/raw6 and packet protocol nodes denote sockets with IP- or link-layer packet craft/sniff capabilities — which significantly expands what an attacker can do post-compromise. Not a cute look.

Bluetooth protocol nodes denote proximity-based attack surface. hci nodes provide raw controller management access and are shown in yellow. rfcomm sockets are reachable by nearby devices without prior host access and, unless the adapter is configured to require pairing, may be reachable without authentication. periodt, that's scary.

Adapter BD_ADDR resolution requires HCI ioctl access; without it, adapter identity is shown as hci?/*.

---

👀 SEE ALSO 👀

• pscap(8)
• filecap(8)
• capabilities(7)
• netstat(8)

---

✍️ AUTHOR ✍️

Steve Grubb — the icon, the legend, the moment 👑

---

and that's the whole page, bestie 🫶 this one shipped from Red Hat and it's dated March 2026, from the NETCAP:(8) manual. go forth, read your caps, trim your bounding sets, and stay unprivileged ✨🦋💖