Sniffing with Wireshark as a Non-Root User
This article focuses on Linux and some UNIXes. For Windows users, there is some good info in the Wireshark wiki.
Many network engineers become dismayed the first time they run Wireshark on a Linux machine and find that they don't have access to any network interfaces. This is because, by default, raw access to network interfaces (e.g. eth0) requires root privileges. Unfortunately, this often prompts people to simply run Wireshark as root - a bad idea. As an older Gentoo Linux ebuild of Wireshark warns:
WIRESHARK CONTAINS OVER ONE POINT FIVE MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.
Indeed, due to the complexity and sheer number of its many protocol dissectors, Wireshark is inherently vulnerable to malformed traffic (accidental or otherwise), which may result in denial of service conditions or possibly arbitrary code execution. But if we shouldn't run Wireshark with root privileges, how are we to capture packets?
The lead developer of Wireshark, Gerald Combs, points out some that Linux distributions are beginning to implement Linux filesystem capabilities for raw network access. In this article, we'll walk through putting this idea into practice on an Ubuntu 9.10 machine, and include a bit more detail behind the system commands.
Filesystem Capabilities
What are filesystem capabilities? From the man page:
For the purpose of performing permission checks, traditional Unix implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is non-zero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list).
Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.
The manual goes on to list over two dozen distinct POSIX capabilities which individual executables may be granted. For sniffing, we're interested in two specifically:
CAP_NET_ADMIN ; Allow various network-related operations (e.g., setting privileged socket options, enabling multicasting, interface configuration, modifying routing tables). CAP_NET_RAW ; Permit use of RAW and PACKET sockets.
CAP_NET_ADMIN allows us to set an interface to promiscuous mode, and CAP_NET_RAW permits raw access to an interface for capturing directly off the wire. These capabilities are assigned using the setcap utility.
Enabling Non-root Capture
Step 1: Install setcap
First, we'll need to install the setcap executable if it hasn't been already. We'll use this to set granular capabilities on Wireshark's dumpcap executable. setcap is part of the libcap2-bin package.
stretch@Sandbox:~$ sudo apt-get install libcap2-bin Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: libcap-dev The following NEW packages will be installed: libcap2-bin 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 17.7kB of archives. After this operation, 135kB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com karmic/universe libcap2-bin 1:2.16-5ubuntu1 [17.7kB] Fetched 17.7kB in 0s (36.7kB/s) Selecting previously deselected package libcap2-bin. (Reading database ... 146486 files and directories currently installed.) Unpacking libcap2-bin (from .../libcap2-bin_1%3a2.16-5ubuntu1_amd64.deb) ... Processing triggers for man-db ... Setting up libcap2-bin (1:2.16-5ubuntu1) ...
Step 2: Create a Wireshark Group (Optional)
Since the application we'll be granting heightened capabilities can by default be executed by all users, you may wish to add a designated group for the Wireshark family of utilities (and similar applications) and restrict their execution to users within that group. However, this step isn't strictly necessary.
root@Sandbox# groupadd wireshark root@Sandbox# usermod -a -G wireshark stretch
After adding yourself to the group, your normal user may have to log out and back in. Or, you can run newgrp to force the effect of the new group (you'll have to launch Wireshark from this same terminal environment in step 3):
stretch@Sandbox$ newgrp wireshark
We assign the dumpcap executable to this group instead of Wireshark itself, as dumpcap is responsible for all the low-level capture work. Changing its mode to 750 ensures only users belonging to its group can execute the file.
root@Sandbox# chgrp wireshark /usr/bin/dumpcap root@Sandbox# chmod 750 /usr/bin/dumpcap
Step 3: Grant Capabilities
Granting capabilities with setcap is a simple matter:
root@Sandbox# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
In case you're wondering, that =eip bit after the capabilities list grants them in the effective, inheritable, and permitted bitmaps, respectively. A more thorough explanation is provided in section 2 of this FAQ.
To verify our change, we can use getcap:
root@Sandbox# getcap /usr/bin/dumpcap /usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip
Now, as the user who we added to the wireshark group in step 2, execute Wireshark. You should now see the full list of available adapters and can begin sniffing. (If not, double-check that the wireshark group is listed in the output of groups. You may need to log out and back in for the new group assignment to take effect.)
Comments
@Dinger: If it did, you'd have to restart the application every time you wanted to re-start a capture.
Nice article!
It sounds very nice, unfortunately something must be missing for openSUSE 11.2 :
% sudo zypper install libcap-progs % sudo groupadd wireshark % sudo usermod -G wireshark jc % sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap % getcap /usr/bin/dumpcap /usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip % groups users wireshark %wireshark [...] dumpcap: There are no interfaces on which a capture can be done
Good article. You can also use dpkg-statoverride on debian based systems to set file modes and ownership. Dpkg-statoverride keeps a database of the modifications and applies them to the files again, when you upgrade software packages. However it doesn't support capabilities at the moment.
root@Sandbox# dpkg-statoverride --add root wireshark 750 /usr/bin/dumpcap root@Sandbox# dpkg-statoverride --list /usr/bin/dumpcap root wireshark 750 /usr/bin/dumpcap root@Sandbox# ls -l /usr/bin/dumpcap -rwxr-x--- 1 root wireshark 58676 2009-10-25 05:33 /usr/bin/dumpcap
Regards,
Jochen
Solaris has had privileges for ages, in this case net_rawaccess. I run Cacti with SMF granting the net_icmpaccess privilege so tools like fping need not be setuid to work.
That said, I never use Wireshark to capture packets. Do you really want a sizeable fraction of those 1.5M lines of code in the way of each packet? I always capture using tcpdump (or Solaris' snoop) as root to a file, then read the file with Wireshark, sometimes on a completely different system.
@phocean: Did you do the following?
chgrp wireshark /usr/bin/dumpcap chmod 750 /usr/bin/dumpcap
If so, you may just need to log out and back in. If not, I'm not sure what's up with it. =\
@Fazal Majid: Wireshark itself doesn't capture packets (though it did prior to version 0.99.7); that's handled by the dumpcap executable, which is similar to tcpdump. It's a very lightweight executable:
stretch$ ls -lh `which dumpcap` -rwxr-x--- 1 root wireshark 63K 2009-10-25 00:28 /usr/bin/dumpcap
Also, the use of filesystem capabilities as demonstrated in the article can be applied to tcpdump as well, to avoid having to run it as root.
@stretch: Yes, I did that so there must be another issue. If I ever find, I will update here.
Another great article, Stretch!
I'm glad to see another network engineer concerned with system security. I used to copy and paste that warning from the ebuild into any thread I saw that suggested using Wireshark to capture packets. It's cool to see that there's a way around that these days.
@phocean: Hey, see if CONFIG_SECURITY_FILE_CAPABILITIES is enabled in your kernel config. If not, filesystem capabilities need to be enabled.
@stretch: Good idea, thank you for checking. Unfortunately, that was activated :
% uname -r 2.6.31.12-0.1-desktop % grep CONFIG_SECURITY_FILE_CAPABILITIES /boot/config-2.6.31.12-0.1-desktop CONFIG_SECURITY_FILE_CAPABILITIES=y
@stretch: Ok, I found out. Actually, it was necessary to activate the capabilities at boot time.
So I added the following line in /boot/grub/menu.lst, kernel field :
file_caps=1
@phocean: Ha! Weird. Glad you solved it, and thanks for posting the solution!
AppArmor and SELinux protect me even root cant pwn
Hi,
This looks cool but I am having trouble using this on CentOS 5 which is not Debian.
Does anyone know of a work around to implement this for CentOS 5?
Thanx,
John
Hi,
I found a LIBCAP2 Source from:
http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/
I installed this with the required dependancies.
The result I get after the install and following the instructions above are:
uname -a
Linux localhost.localdomain 2.6.18-164.15.1.el5PAE #1 SMP Wed Mar 17 12:14:29 EDT 2010 i686 i686 i386 GNU/Linux
setcap cap_net_raw,cap_net_admin=eip /usr/sbin/dumpcap
getcap /usr/sbin/dumpcap
/usr/sbin/dumpcap = cap_net_admin,cap_net_raw+eip
ls -al /usr/sbin/dumpcap
-rwxr-x--- 1 root wireshark 60900 Jun 16 2009 /usr/sbin/dumpcap
When I launch Wireshark as the user in the Wireshark Group I get NO intefaces listed.
Can anyone point me to my error in implementation?
Thanx,
John
Thank you very much for the post. I have spent almost 24hr on this but couldn't figure it out.


Why can't Wireshark drop root after it starts sniffing, a la Apache?