Wireshark-bugs: [Wireshark-bugs] [Bug 10406] Need better mechanisms for allowing non-privileged
Date: Sat, 23 Aug 2014 01:35:26 +0000
Comment # 3
on bug 10406
from [email protected]
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? 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. As an example (just out of the top of my mind, but there are many others), consider what happens when I run apport to report a bug. At some point it asks me whether I want to include some logs that contain information that can help developers investigate the bug - but that also may potentially contain sensible information. When I choose Yes, it needs some privileges to read those files (now I don't know whether they are root or somewhere-below-root privileges), so it asks me for the password. And that's it. Where is the risk? If I let a guest use my computer, and he happens to run that program, even by mistake, he won't be able to grant it those privileges because he needs my sudo password. So, no possible attack by malicious user. And how could any malicious software (other than the one asking for the password and obtaining the privileges) possibly use those privileges? I think the same reasoning applies to Wireshark. Whoever I allow to occasionally use my computer without my supervision, even if he runs Wireshark, won't be able to grant it the privileges for capturing packets when asked to, unless he knows my password. So, that's the mechanism that all programs needing special privileges use in Ubuntu, and the Ubuntu packaged version of wireshark should come with that mechanims by default. Of course the possibility to change that in favour of other mechanisms based on specific needs is much appreciated. But what certainly cannot be the default is that: - you run the program normally and you are unable to do the most obvious thing you need the program for (capturing packets of your main network device) - at first sight you don't have the slightest clue why and may waste a lot of time figuring out (not my case, I simply ran it as root so I got to the following point) (but I guess this is also covered somewhere in the help) - if you do run it as root you're told you shouldn't and you're linked to an 8000 characters page that you need to read and fully understand in order to take the right decision just to get the obvious behavior that you would expect in the first place 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, I don't quite get why "*somewhat*". > 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? 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. 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? (or at least strongly-desktop-oriented derivatives such as Ubuntu) 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 (which is what I guess when you say "the dpkg-reconfigure will give you that") or it will let you choose between any of those two modes (which is what I'd evince from the linked page).
You are receiving this mail because:
- You are watching all bug changes.
- References:
- Prev by Date: [Wireshark-bugs] [Bug 10406] Need better mechanisms for allowing non-privileged users to capture network traffic
- Next by Date: [Wireshark-bugs] [Bug 10406] Need better mechanisms for allowing non-privileged users to capture network traffic
- Previous by thread: [Wireshark-bugs] [Bug 10406] Need better mechanisms for allowing non-privileged users to capture network traffic
- Next by thread: [Wireshark-bugs] [Bug 10406] Need better mechanisms for allowing non-privileged users to capture network traffic
- Index(es):