Granting Wireshark capture privileges does not allow USB capture

Bug #893828 reported by Paul Robinson
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
wireshark (Ubuntu)
Opinion
Undecided
Unassigned

Bug Description

Mentioned this at

https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/758916

Moved it here at Evan Huus's request. Two relevant posts from that thread:

Paul Robinson (funwithlibelium wrote 3 hours ago: #16

Hello,

I'm running Ubuntu 10.11 on a single user Lenovo laptop. Wireshark is 1.6.2., libpcap is 1.1.1-8.

To the best of my ability, I set up Wireshark according to 1./b. in /usr/share/doc/wireshark-common/README.Debian, that is, dpkg reconfigured wireshark-common, made a wireshark group and added myself to it so Wireshark itself didn't have to run as root.

I'm on this Linux/Wireshark journey because I need to look at USB packets on this computer, and Wireshark has that ability.

When I start Wireshark from the Ubuntu GUI, the following four choices show up under the capture Interface List: eth0, wlan0, Pseudo-device..., lo. I can start a capture on wlan or Pseudo... and see all kinds of gobbledegook. But no USB choices appear.

After tearing my hair out for a good long time, I mean learning a lot, I asked a person with more Linux experience than I have to take a look. After a while, he tried opening a terminal and typing

sudo wireshark

Voila, there were the USB interfaces, and they work.

So, it seems in my case, to get one of Wireshark's advertised features, I must run it as root, and receive the mentioned warning and the error in the title of this thread.

Or, I'm doing something wrong, and I hope one of you will gently point me in the right direction.

Paul
Evan Huus (eapache) wrote 2 hours ago: #17

The way I understand it is that you've run across a different bug: namely that granting Wireshark capture privileges (which it sounds like you did correctly, given that you can capture on the network interfaces), does not grant it USB capture privileges.

I'm not on an Ubuntu machine right now, but I'll do some digging when I get home this evening and see if I can figure out what's going on. In the meantime, I would appreciate it if you could file a new bug for this issue by running the command 'ubuntu-bug wireshark'. I'd rather not clutter up the comments thread on this one if it can be helped.

Thanks,
Evan

---
Ubuntu Bug Squad Volunteer
https://wiki.ubuntu.com/BugSquad

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: wireshark 1.6.2-1
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic-pae 3.0.6
Uname: Linux 3.0.0-13-generic-pae i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Tue Nov 22 16:17:48 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: wireshark
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Paul Robinson (funwithlibelium) wrote :
Revision history for this message
Evan Huus (eapache) wrote :

With a little testing I have been able to confirm this bug. I'll have to do further work to figure out the why, but it is definitely reproducible.

Changed in wireshark (Ubuntu):
status: New → Confirmed
Revision history for this message
Evan Huus (eapache) wrote :

My apologies for the rather extensive delay. Other things came up, and it took me longer than I thought it would to figure out what was going on.

Short answer: running "sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip CAP_DAC_OVERRIDE+eip' /usr/bin/dumpcap" should grant you the ability to capture USB packets as non-root (as long as you're in the wireshark group, of course). This is a *workaround*, and is not-nice from a security perspective (although it's still better than running the whole of wireshark as root). More details are below the cut.

---

Running dpkg-reconfigure as you did simply automates the steps listed at [1] and [2]. This uses the linux capabilites subsystem [3] to grant the dumpcap program (the part of wireshark that actually does the capturing) the NET_RAW and NET_ADMIN capabilities so it can capture on network interfaces without full root privileges.

The USB capture component of dumpcap uses a different interface from the network capture, as the kernel exposes the two types of devices in different ways. The USB devices are exposed via the /dev/usbmonXXX device files, which are read/writable by root only. Setting the NET_* capabilities has no effect on dumpcap's ability to access those files.

Unfortunately, the only capability I've found that does grant dumpcap the ability to access those files is the DAC_OVERRIDE capability (DAC stands for Discretionary Access Control). With this capability, dumpcap can read/write to ANY file on the filesystem regardless of that file's permissions or owner. This means it can access the USB device files, but it also means it gets access to all the other dangerous files on the filesystem.

The optimal solution would be for Linux to provide more fine-grained capabilities so that it is possible to grant dumpcap USB access without all of the other dangerous stuff that comes with it. For now, it's understandable why Wireshark doesn't want to open up that security hole by default.

If anything is unclear, please don't hesitate to ask.

Evan

[1] http://wiki.wireshark.org/CaptureSetup/CapturePrivileges#Setting_network_privileges_for_dumpcap
[2] http://wiki.wireshark.org/CaptureSetup/CapturePrivileges#Limiting_capture_permission_to_only_one_group
[3] http://linux.die.net/man/7/capabilities

Revision history for this message
Balint Reczey (rbalint) wrote :

Evan: Thank you for the detailed explanation.

Paul: Not allowing capturing on USB to a regular user is intentional. Keep in mind that keyboards and storages can be attached via USB and in those cases the user would be allowed to read any file on the attached storage
or log keys. Wireshark 1.6.5-2 or 1.6.6-1 will contain an updated README.Debian covering capturing USB packets.

Revision history for this message
Evan Huus (eapache) wrote :

Closing this as opinion, as even if Linux were to offer more fine-grained security controls we might not use them (due to the security concerns Balint mentioned).

Changed in wireshark (Ubuntu):
status: Confirmed → Opinion
Revision history for this message
Stefan Tauner (stefanct) wrote :

Similar arguments can be brought up against allowing a user to capture network traffic. So arguing against it - at least if there were a fine-grained option in the kernel - is not convincing, especially if it is disabled by default as the network privilege is ATM. And if there were such a capability then it would be obviously safer and better to run wireshark as non-root if you have to capture USB packets, which isn't too uncommon for hardware developers (I am in that situation right now ;). Hence this is *not* an opinion but a bug (not only in wireshark, but also/mainly in the kernel). Did anybody know what the kernel guys think about adding a finer-grained capability for this? I won't reopen the bug for now mainly because it does not make sense, if the Debian (and an Ubuntu) maintainer just not agrees with the above :) I encourage you to do so and add the kernel though.

Revision history for this message
Balint Reczey (rbalint) wrote :

@Stefan: I think if a system uses NAS , which would allow a user being able to capture netwok packets read files, the syste admin would not allow capturing network packets as normal users.

You can still allow normal users to capture USB packets using wireshark by setting the setuid bit on dumpcap and making this change permanent using dpkg-statoverride as suggested in README.Debian:

      Note that capturing USB packets is not enabled for non-root users by using
      Linux Capabilities. You have to capture the packets using the method
      described in I./a., setting the set-user-id permanently using
      dpkg-statoverride or running Wireshark as root.

This opens a security hole on the system as detailed above.

Revision history for this message
Stefan Tauner (stefanct) wrote :

"I think if a system uses NAS…" I meant it more generally: information leaks on networks are so common that you can compare the thread level to that of a sniffable USB.

"This opens a security hole on the system as detailed above." That's exactly my point, this should not be needed, because it greatly increases the threat potential due to unnecessarily granted privileges. It is just a poor workaround for the missing capability setting in the kernel.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.