[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 5 on bug 10406 from Guy Harris

(In reply to teo8976 from comment #2)
> Thank you for improving my terrible phrasing of the bug title and for taking
> it finally into consideration.
> 
> 
> That all is very interesting (no sarchasm here), but still leaves me (and
> most other non-hacker, non-sysadmin-literate but still
> kind-of-know-what-im-doing  users that just want to use Wireshark to capture
> a few packets) with a question: what the f*** should I do, then?

On sufficiently recent Debian derivatives, you do "dpkg-reconfigure
wireshark-common"; if the Debian people don't want to make that the default,
perhaps they should at least either make the installation process offer that as
an option to the person doing the installation (watch out for the dancing pigs,
though) or patch Wireshark to offer that when you try to capture (run that
command as root within the usual graphical sudo tool).

On OS X, the default installation with the packages from wireshark.org install
a startup item or launch daemon that makes all the BPF devices writable by
group bpf_access and puts you into that group.

On other UN*Xes, it's different.

> Please keep in mind that we are (or at least I am) talking about the
> specific case of Wireshark as it comes packaged for Ubuntu and similar
> debian-based-or-similar DESKTOP linux distros here. Not wireshark in general
> in all possible OSes and use scenarios (including a computer shared by a lot
> of people that barely know each other) which of course present a lot of
> caveats as you describe.

Yes, but we, the Wireshark developers, have to worry about Wireshark in general
in all possible OSes and use scenarios, so I won't be talking only about that
specific case.

It may be that having Wireshark/TShark run a "run dumpcap with just the
privileges that it needs" through sudo (TShark) or a graphical equivalent
(Wireshark) will not be subject to the dancing pigs problem.  It does avoid the
problem of some other untrusted program being able to capture by running
dumpcap directly.

> If I understand correctly, the "usual ubuntu way" which I am claiming for
> should be this one, right?:
> > A mechanism in which dumpcap isn't granted special privileges by default, and in which Wireshark/TShark/etc. can run some helper program that runs another program with sufficient privileges (and requires you to provide your password, e.g. some GUI program for Wireshark and sudo for TShark/dumpcap itself) might *somewhat* give you that,

Yes.

> I don't quite get why "*somewhat*".

The ideal would be a situation in which:

    blessed sniffers, when run by somebody allowed to do sniffing, do so
without prompting you;

    other programs can't do that;

although that would require that other programs not be allowed to run blessed
sniffers.  Solving *that* might require sandboxing.

> > although you'd want to make sure it doesn't leave you open to the dancing pigs problem:
> 
> I don't see how it could. If I understand correctly, the "dancing pig
> problem" is when security relies upon some prompt that is guaranteed to be
> displayed by the system regardless of the program that triggers that prompt,
> but a (malicious) program may trick the user into choosing the wrong option
> even if it can't hide the system's prompt/warning by adding some distracting
> or confusing information. Right?

An example would be an e-mail, with an attachment, saying "click this to watch
the dancing pigs!"; the OS might say "hey, that's an un-trusted program, do you
*really* want to run that?", and the user would say "of *course* I want to run
that, I'm trying to see the dancing pigs!"

> But here we're talking about Wireshark and
> only Wireshark asking for a permission. How could that in any way allow any
> other program to misuse that? Perhaps I'm missing something.

These days, my default assumption, when it comes to security issues, is "I
could be missing something"; only with a significant amount of analysis do I
drop that assumption.

> 
> 
> As an aside note:
> 
> ""
> I./a. Installing dumpcap without allowing non-root users to capture packets
> (...)
> This is the default on Debian systems.
> 
> I./b. Installing dumpcap and allowing non-root users to capture packets
> (...)
> This is the preferred way of installation if Wireshark/Tshark will be used
> for capturing and displaying packets at the same time
> ""
> 
> I see a contraddiction here. If I./b is the preferred way (if WS will be
> used for... which is the most common case), then why isn't it the default on
> Debian systems?

Ask the Debian developers why that's not the default.  Perhaps the answer is
"that lets arbitrary programs run dumpcap", in which case requiring the user to
provide a password (and be otherwise allowed to run the capturing program with
elevated privileges) to run the capturing program with privileges (most of
which it should give up once it's opened the device on which it's capturing)
may be a better answer.

> P.S.
> 
> "The installation method can be changed any time by running:
>  dpkg-reconfigure wireshark-common"
> 
> It's not entirely clear (to me at least) whether that command will switch to
> the "I./b" mode

Yes.

---

      You are receiving this mail because:

• You are watching all bug changes.