Why should Wireshark never run as root, and how do you let a non-root analyst capture packets on a Linux host?

## Why not run Wireshark as root Wireshark's dissectors are an enormous body of code — the developer guide speaks of **millions of lines** — and their job is to parse whatever arrives on the wire, which is input an attacker can shape. A parsing bug in a process running as root hands the attacker root. The project's answer is **privilege separation**: - All function calls that need elevated privileges live in **dumpcap**. When you capture from the GUI or from tshark, they start dumpcap as a separate process and read packets from it. - The developer guide says in capitals not to run the rest as root, and Wireshark and tshark print warnings when started with elevated privileges; tshark, for instance, reports the user and group it is running as and adds "This could be dangerous." - dumpcap itself sheds what it does not need: on Linux it keeps only `CAP_NET_RAW` (opening capture sockets) and `CAP_NET_ADMIN` (promiscuous mode, among much else) and drops every other capability; if it was started setuid root it gives up the setuid identity while keeping those two. How Linux capability sets work in general is a Linux subject; here they matter only as the thing dumpcap needs and the GUI must not have. ## Three ways to grant capture on Linux | Method | How | Who can capture afterwards | |---|---|---| | Distribution package (Debian, Ubuntu) | `sudo dpkg-reconfigure wireshark-common`, answer yes to "Should non-superusers be able to capture packets?", then `sudo usermod -a -G wireshark <user>` and log in again | members of the `wireshark` group | | File capabilities | `sudo setcap cap_net_raw,cap_net_admin=ep /path/to/dumpcap` | every user who can execute dumpcap | | setuid root | `chmod 4750` with a dedicated group | members of that group; the developer guide prefers setcap on Linux | Whichever you choose, the right goes on **dumpcap**, never on the `wireshark` or `tshark` binaries. ## Restricting who may capture Enabling setcap or setuid installation **allows packet capture for all users** who can run dumpcap — and capture reads every packet crossing the host, including other users' unencrypted credentials and session data. On a shared host, restrict execution to a group, in this order: 1. Create a group for capture, for example `groupadd packetcapture`. 2. `chgrp packetcapture /usr/bin/dumpcap` 3. `chmod 750 /usr/bin/dumpcap`, so only the owner and that group can execute it. 4. `setcap cap_net_raw,cap_net_admin+ep /usr/bin/dumpcap` as the last step, as the developer guide's example does. Two related details: - dumpcap's `-g` option creates output files with **group-read** permission, which is how you share a capture with the group deliberately rather than by loosening the directory. - A capture file is sensitive data in its own right; store it where the same group, and no wider audience, can read it. ## Other platforms and remote hosts - **Remote Linux hosts:** Wireshark's **sshdump** interface runs a capture tool on another machine over SSH and streams the packets back. It requires the remote capture executable to have the capabilities to capture, or it elevates with `--remote-priv` (none, sudo or doas). The rule does not change: the privilege belongs to the remote capture binary, and the analysis stays on your unprivileged workstation. - **macOS:** capture needs access to the BPF devices. The Wireshark package provides the **ChmodBPF** launch daemon (`Install ChmodBPF.pkg` in the disk image, or **About Wireshark > Folders > macOS Extras**), which grants a group that access at boot. - **Windows:** capture goes through the Npcap driver, which can be installed so that only Administrators may use it — a stricter setting with the same intent of limiting who can capture. ## Recognising a permission problem - dumpcap reports `You do not have permission to capture on device "eth0"`, and the GUI shows platform-specific advice: the `dpkg-reconfigure` route and the `setcap` command on Linux, ChmodBPF on macOS. - After adding a user to the `wireshark` group, the change applies only to **new login sessions**; an analyst who stays logged in keeps failing. - An interface the user cannot open may simply be **missing** from Wireshark's interface list rather than producing an error, so check as the analyst with `dumpcap -D` before deciding the host has no such interface. - Running `sudo wireshark` "to make it work" is the wrong fix: it runs every dissector as root, the exact risk the design avoids.