No capture support

[eszlari]

https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

Wireshark has implemented Privilege Separation which means that the Wireshark GUI (or the tshark CLI) can run as a normal user while the dumpcap capture utility runs as root. This can be achieved by installing dumpcap setuid root. The advantage of this solution is that while dumpcap is run as root the vast majority of Wireshark's code is run as a normal user (where it can do much less damage).

[muelli]

I don't think we can make the flatpak have capture support. Or do you happen to know a way?

[Lekensteyn]

Network capturing support requires cap_net_admin and cap_net_raw.
USB capture requires read access to /dev/usbmon*.

I am not familiar with Flatpak sandbox limitations so cannot comment on its feasibility.

[eszlari]

USB capture requires read access to /dev/usbmon*.

This can be achieved by adding --device=all to finish-args.

[eszlari]

I don't think we can make the flatpak have capture support. Or do you happen to know a way?

Maybe something like:

1. bundle a statically linked dumpcap binary with the flatpak
2. copy dumpcap binary from the sandbox to the host filesystem
3. setcap or chown the dumpcap binary on the host
4. execute dumpcap binary on the host from inside the sandbox with flatpak-spawn --host

[wjt]

Maybe something like:

1. bundle a statically linked dumpcap binary with the flatpak
2. copy dumpcap binary from the sandbox to the host filesystem

There is no need to copy it – you can look in /.flatpak-info at the [Instance] app-path key to find the path to the app's files on the host system

3. setcap or chown the dumpcap binary on the host
4. execute dumpcap binary on the host from inside the sandbox with flatpak-spawn --host

My favourite hammer is running flatpak-spawn --host pkexec /path/to/privileged/tool. This is what Bustle, a D-Bus traffic monitor, does, although it relies on the host having pkexec and dbus-monitor installed. Here are the relevant bits of code. I don't know if there's something similar to pkexec that one can use to prompt a user for permission to run an arbitrary command with certain capabilities.

[eszlari]

This is what Bustle, a D-Bus traffic monitor, does,

How does this work without adding --talk-name=org.freedesktop.Flatpak to
https://github.com/flathub/org.freedesktop.Bustle/blob/master/org.freedesktop.Bustle.yaml

[LorenzoAncora]

Wireshark is almost useless without capture support.
If the problem cannot be resolved, it would be appropriate to remove the package from Flathub.

[Erick555]

I don't see user friendly way to make capture work so +1 for removal. Broken or half-broken apps don't benefit flathub.

[TingPing]

It was mentioned during review: flathub/flathub#809 (comment)

The application can still read captured data from outside the sandbox was the only counter. I think barely useful applications makes flatpak look bad but thats just me.

[muelli]

I don't think that the app is broken. At all.
Given that protocol parsers are often broken and allow for memory corruption, running the analyser in a sandboxed environment is tremendously helpful.

[TingPing]

Its not broken, its just forever limited in functionality in a way that users don't expect and will always lead to disappointment.

[crondaemon]

Guys, sorry for jumping in the discussion with few knowledge of flathub. I just wanted to point out that wireshark can leverage nflog kernel interface. Would it be possible to use it to circumvent the problem?

[Erick555]

The example shows it still uses dumpcap which needs cap_net_admin and cap_net_raw so it doesn't look different. It also needs special iptables rules...

Given that protocol parsers are often broken and allow for memory corruption, running the analyser in a sandboxed environment is tremendously helpful.

Same thing could be said about browsers, should we add firefox without networking support to flathub then? It will still open local files...

[Erick555]

USB capture requires read access to /dev/usbmon*.

This can be achieved by adding --device=all to finish-args.

/dev/usbmon* is restricted to root (at least in Arch) so --device=all alone may not help.

[muelli]

Same thing could be said about browsers, should we add firefox without networking support to flathub then? It will still open local files...

I think the way you present your argument is making it weaker than it is. By relating to other use-cases you are evading the points that have been made and it appears as if you can't address them.

Having said that, if looking at locally stored files is a major use-case, then I'd say yes, let's provide an isolated version of that app. But it's a bad example for various reasons. One of them being that we can allow the establishment of network connections for flatpaked apps. The other is that, yes, we do have flatpaked browsers on flathub. And one of the reasons is that browsers tend to have a large attack surface and are under attack frequently.

[Lekensteyn]

Wireshark is also commonly used to inspect traffic from other sources:

• pcap from customers
• remote capture over ssh (does not need local capture privileges)
• inspect a capture file from running tcpdump in a Docker container

So while capture support is essential for local debugging, I would not go as far and claim that it makes the Flatpak useless. But I concur that capture support is very important for many users.

I updated https://wiki.wireshark.org/CaptureSetup/NFLOG to clarify that CAP_NET_ADMIN is required (CAP_NET_RAW is not required for NFLOG).

[crondaemon]

I was going to say what @Lekensteyn said, but he arrived first. During Sharkfest, the user and developer Wireshark conference we meet a lot of people using Wireshark as analysis engine, not capture engine. Capture engines (dumpcap, tcpdump, others) have much less memory limitations than Wireshark. Then it's very common to split the capture phase by the analysis, using Wireshark just in the latter. Again, capture support is very important, but it's not so necessary to make Wireshark without it a useless toy. Another story is a Internet browser without the network support: that's a useless toy.

[Erick555]

I think the way you present your argument is making it weaker than it is. By relating to other use-cases you are evading the points that have been made and it appears as if you can't address them.

All the points were addressed by me and others. Capture doesn't work and won't work and you can't deny that. For some people it will mean broken for others useless and for most disappointing but all will agree there is inherent vice there.

The other is that, yes, we do have flatpaked browsers on flathub

Really, where?

@Lekensteyn currently wireshark flatpak doesn't have network or ssh access so amount of potential use cases is really minimal.

I know that for some people offline use will be enough but why someone would chose flatpak demo version over downloading full featured version from other source which can work in all scenarios?

[Lekensteyn]

@Erick555 For Windows and macOS, our users can find the latest stable and testing versions at https://www.wireshark.org/download/. For Linux, we rely on distributions to build a version that integrates well with their systems (reusing system libraries, etc.). I use Arch Linux and can always have the latest stable version, but users on Debian and Ubuntu tend to lag severely behind.

Users who need the latest features or protocol support could try to use the Flatpak version in combination with dumpcap from the distribution, for the lack of an easier and better alternative. The best alternative is to build it from source, git master is quite stable. However not all users have the time and resources to do this.

We should probably investigate other distribution methods for Linux, including:

• AppImage - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14464
• Update the Ubuntu PPA more regularly with the latest stable version (3.2.2 at the moment). It is maintained by @rbalint who has already updated Debian testing/unstable, but the PPA lags behind at the moment.
• Maybe leverage platforms like OBS to target (other) distros?

[rbalint]

@Lekensteyn I've just uploaded 3.2.2 to the staging PPA and will update the stable PPA if it builds fine.
For the record Ubuntu 20.04 already has 3.2.2, too.

[Erick555]

@Lekensteyn I think appimages will have similar issue with capture support. You may look at snap. They support interfaces that grant special privileges for chosen apps.

EDIT: it seems capture support for wireshark snap isn't possible yet.

[Erick555]

BTW: does wireshark keep backward compatibility between gui and cli parts?

[eszlari]

Would a portal based solution even be possible?

[Lekensteyn]

@rbalint Wow that was fast, thank you for updating the PPA!

@Erick555 AppImage is not sandboxed. While the filesystem cannot be changed, perhaps you could use ambient capabilities to be able to capture anyway, see https://www.wireshark.org/lists/wireshark-dev/201711/msg00025.html
What OS are you using? If it is Ubuntu, consider using the PPA.

WIreshark for the most part aims to keep backwards compatibility, but you can check the release notes to be sure. Interfaces are generally stable within a stable release.
https://www.wireshark.org/docs/relnotes/

[Erick555]

@Lekensteyn I'm using Arch Linux so I don't have issues with running latest wireshark and I'm not asking for solution for myself. Using sudo wrapper with appimage, even if technically work is still not very user friendly 😄

[TingPing]

@Lekensteyn It would be an interesting idea to have a small DBus service on the host that captures and forwards it to clients. So while that service will always have to exist on the host it would be small and presumably a stable interface.

[Lekensteyn]

Somewhat related to this topic, a thread about possible Linux distribution formats for Wireshark: https://www.wireshark.org/lists/wireshark-dev/202003/msg00034.html

@TingPing Aside from capturing packets, it would also become responsible for setting interface options (promiscious and data link type), handling rotation, compiling BPF code (libpcap), etc. It does not seem likely for this to become a standardized DBus interface?

[LorenzoAncora]

Until a decision is made, I suggest that it would be advisable to insert a note on its descriptive page explaining that the capture support is not available.

Example:

---

---

Adding such a note is a sign of respect for end users. When and if the problem is solved the note will be removed.

[barthalion]

I still think it's valuable to have it on Flathub. I usually capture traffic on servers and then analyze pcap files locally. A note in appdata (and possibly hiding capture options in menu, at least obvious ones?) would be good though.

[LorenzoAncora]

A note in appdata (and possibly hiding capture options in menu, at least obvious ones?) would be good though.

The note should be visible before downloading, so that end users can decide whether this limitation is acceptable to them before installing.

[TingPing]

It does not seem likely for this to become a standardized DBus interface?

@Lekensteyn It doesn't need to be standardized. The concept of "portal" just means "safe" dbus service on the host (safe can just mean in this case that it asks the user for permission, not that it isn't privileged information). It would allow users to install wireshark-service from their distro and the wireshark application from $sandboxed_format.

[barthalion]

The note should be visible before downloading, so that end users can decide whether this limitation is acceptable to them before installing.

Which is what appdata is. I assume if someone uses CLI to install anything, they're also aware of various limitations of flatpak.

[Lekensteyn]

@TingPing While Portals do not necessarily require standardization at the distro/Flatpak level, it certainly requires coordination between the hypothethical wireshark-service and consuming application (Wireshark). This will not solve the problem of making capture support available out-of-the-box since users will still have to manually install the external service. Shipping 'dumpcap' directly in this external service also seems rather unlikely due to extra system-specific dependencies (glib, libwsutil + deps).

Some of the functions provided by dumpcap:

• Rely on the libpcap library to compile capture filters into cBPF, and pass this to the capture socket.
• Rely on the libpcap library to discover interfaces. If libpcap was linked with DBus/Bluetooth/USB support, then those will also be available in addition to typical interfaces such as eth0, wlan0 and lo.
• The ability to change the Data Link Type (DLT), for example to enter 802.11 monitor mode for wireless interfaces.
• Capture file rotation depending on conditions such as duration, file size, packet count, etc.
• Other options at https://www.wireshark.org/docs/man-pages/dumpcap.html

In the future, perhaps there will also be ways to record process info in addition to packets. Whether this will be done, and how this is done is not known yet, but it might require some privileged helper such as dumpcap or another process. Right now dumpcap is upgraded in lockstep with Wireshark, so it is reasonably easy to change the undocumented private interface, that might not be the case with an external service.

It should be possible to design such a portal, but if all of the dumpcap functionality is implemented there, then it will be rather complex.

A possible alternative is to open the AF_PACKET socket in the helper, and somehow pass the fd to the Flatpak and implement things like file rotation there, but it still requires some nifty engineering. And of course there is the question of security, normally the file group will constrain who will be able to capture packets. How can the Portal be restricted to users in said group, and is it possible to reduce the risk of exploiting the service by other malicious flatpaks?

References:

• https://github.com/flatpak/flatpak/wiki/Portals
• https://flatpak.github.io/xdg-desktop-portal/portal-docs.html
• https://docs.flatpak.org/en/latest/portal-api-reference.html

[LorenzoAncora]

The note should be visible before downloading, so that end users can decide whether this limitation is acceptable to them before installing.

Which is what appdata is. I assume if someone uses CLI to install anything, they're also aware of various limitations of flatpak.

@barthalion I don't think you (or anyone else) really have a way to infer end user skills. I could be wrong, but logic says that an individual cannot correctly judge a collectivity.

I think the note should be also visible in the page of Flathub as all users should be informed that the app has partial functionality before they attempt to download it. Please add a note, then you will have plenty of time to find a solution with serenity. :-)

[TingPing]

Shipping 'dumpcap' directly in this external service also seems rather unlikely due to extra system-specific dependencies (glib, libwsutil + deps).

It is fewer and more easily manageable deps than Qt. That is the main thing accomplished.

How can the Portal be restricted to users in said group, and is it possible to reduce the risk of exploiting the service by other malicious flatpaks?

Well the portal process would run as the user so thats that. By default flatpaks cannot talk to any DBus service so this would have a very explicit --talk-name=org.wireshark.SUPERPRIVILEGEDTHING

[atmouse-]

workaround?

#!/bin/sh

[ "x$1" = "x" ] && exit 1

sudo /bin/sh -c "pwd"
sudo /bin/sh -c "mkfifo /home/user/tcpdump"
sudo /bin/sh -c "tcpdump -i $1 -nn -U -w - > /home/user/tcpdump" &

sleep 2

flatpak run org.wireshark.Wireshark -i /home/user/tcpdump
sudo /bin/sh -c "rm -f /home/user/tcpdump"

You could use pipeline file passthrough in sanbox like this. seems break privileges unfortunately.

[kurobeats]

I'd like to point out the following on the Flathub page is misleading as to what this package will allow users to do:

Wireshark allows you to examine protocol data stored in files or as it is captured from wired or wireless (WiFi or Bluetooth) networks, USB devices, and many other sources.

[hadess]

@kurobeats I suggest opening a new issue saying the appstream data is inaccurate. Rather than get lost in this noise.

This was done in #76 and should be fixed by #119

[muelli]

https://flathub.org/apps/details/org.wireshark.Wireshark