Bug 765716
| Summary: | libpcap should be linked with libnl | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Guy Harris <gharris> |
| Component: | libpcap | Assignee: | Michal Sekletar <msekleta> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | b38617, dcbw, msekleta |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-29 00:14:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Adding libnl-devel to BuildRequires causes libpcap to be linked against this library and using it's API instead of Wireless Extension which is definitely good. On the other hand running for example the following command multiple times: # tcpdump -i wlan0 -I -q -c 5 will cause multiple monX interfaces to be present afterwards. libpcap is currently unable to delete monX interface properly and it has to be done manually: # iwconfig dev monX del So far this is my only concern with this change. Any further discussion is every very welcome and appreciated. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Problem with tcpdump mentioned in comment #1 is that if we link against libnl we ask kernel to create/delete monX interface via netlink. To send netlink messages we have to have capability to do that. We don't have it anymore when deleting monX interface because we dropped root and tcpdump is running unprivileged. This is something which should be fixed in tcpdump. Other programs might have the same problem.
For this bug:
1) I'd like to have libpcap directly talk to netlink, avoiding libnl entirely (it already has code that talks to netlink, and that also avoids cases where libpcap uses libnl version N and some application using libpcap uses libnl version M) - at that point, it'd just be a case of RH/Fedora adopting the new version of libpcap;
2) the underlying permissions problem is broader, and doesn't just involve Linux or 802.11 interfaces, and should also be addressed as much as possible by libpcap and, to the extent that libpcap can't handle it, by the programs using it. (The joys of using a permissions model created in the 1970's in a world where there's more trust of users, at least on single-user systems, and *less* trust of code.)
So closing it is the right answer.
You should use libnl3 instead of libnl. "libnl" refers to all three binary-and-source-incompatible versions of libnl. libpcap should not use libnl *at all*; any library that's gone through three incompatible major versions is something to avoid. (In reply to Guy Harris from comment #6) > "libnl" refers to all three binary-and-source-incompatible versions of libnl. "libnl" in Fedora is libnl-1.1.x > libpcap should not use libnl *at all*; any library that's gone through three > incompatible major versions is something to avoid. libnl-3 has a stable API/ABI: http://lists.infradead.org/pipermail/libnl/2011-March/000218.html (In reply to Guy Harris from comment #4) > Other programs might have the same problem. > > For this bug: > > 1) I'd like to have libpcap directly talk to netlink, avoiding libnl > entirely (it already has code that talks to netlink, and that also avoids > cases where libpcap uses libnl version N and some application using libpcap > uses libnl version M) - at that point, it'd just be a case of RH/Fedora > adopting the new version of libpcap; Hmm...Very well then, I'll rebuild once again without linking against libnl and preserve the staus quo for now. Are we aiming to write our own small netlink wrapper/library in the long run? > > 2) the underlying permissions problem is broader, and doesn't just > involve Linux or 802.11 interfaces, and should also be addressed as much as > possible by libpcap and, to the extent that libpcap can't handle it, by the > programs using it. (The joys of using a permissions model created in the > 1970's in a world where there's more trust of users, at least on single-user > systems, and *less* trust of code.) Agreed. Not sure how to approach this in libpcap tough. I don't think we can somehow mess with permissions of applications in libpcap itself at least not by default. What we could do is to provide some API which would allow to create more secure applications with ease. This could be achieved in more ways, for example, libpcap could change effective capabilities at application runtime as needed, or spawn new privileged process and forward requests for actions requiring privileges and drop those in application. > > So closing it is the right answer. (In reply to Michal Sekletar from comment #8) > (In reply to Guy Harris from comment #4) > > Other programs might have the same problem. > > > > For this bug: > > > > 1) I'd like to have libpcap directly talk to netlink, avoiding libnl > > entirely (it already has code that talks to netlink, and that also avoids > > cases where libpcap uses libnl version N and some application using libpcap > > uses libnl version M) - at that point, it'd just be a case of RH/Fedora > > adopting the new version of libpcap; > > Hmm...Very well then, I'll rebuild once again without linking against libnl > and preserve the staus quo for now. Are we aiming to write our own small > netlink wrapper/library in the long run? That's my goal. (Jakub Zawadzki, I think, noted that we already have some code in libpcap that talks directly to netlink sockets for some of the netlink sniffer mode.) I wouldn't be inclined to use libnl until 1) libnl versions 1 and 2 are completely gone from the face of the earth and 2) there still is no libnl version 4. > Agreed. Not sure how to approach this in libpcap tough. I don't think we can > somehow mess with permissions of applications in libpcap itself at least not > by default. What we could do is to provide some API which would allow to > create more secure applications with ease. This could be achieved in more > ways, for example, libpcap could change effective capabilities at > application runtime as needed, or spawn new privileged process and forward > requests for actions requiring privileges and drop those in application. I suspect the latter will be involved (the ability of an app to give up a privilege and later reclaim it, e.g. the saved set-user ID, isn't all that useful as a security mechanism, except in processes running code that you know can't be forced to run random injected code), but, as this is a multi-OS issue, this is probably best discussed in the issues list of the libpcap GitHub repository. |
Description of problem: libpcap's configure script, when run on Linux, checks to see whether libnl is present and usable and, if so, uses it to create monN interfaces when monitor mode is requested for 802.11 adapters. This is used by tcpdump, and by TShark and dumpcap from the Wireshark distribution, to support a "-I" flag (capital-"i") to support capturing in monitor mode, and is used by Wireshark to support a "capture in monitor mode" checkbox. Using libnl to create a monN interface works better than using Wireless Extension ioctls to turn on monitor mode, which is what libpcap does if *not* linked with libnl. Version-Release number of selected component (if applicable): 14:1.1.1-4.fc16 (to quote Apper) How reproducible: Run ldd on the libpcap shared library to find out what libraries it's linked with. Steps to Reproduce: 1. ldd /usr/{lib,lib64)/libpcap.so 2. ??? 3. Profit! Actual results: libnl not mentioned in the output of ldd. Expected results: libnl mentioned in the output of ldd. Additional info: Depending on how the Fedora build process works, this might be the result of libnl not being given in the BuildRequires section of libpcap.spec - if the build process runs the configure script, and libnl *and* libnl-devel aren't present when the configure script is run, the configure script won't find libnl and will build without it. This shouldn't break binary compatibility with programs built with the libpcap shared library - libpcap is explicitly linked with libnl, so the run-time linker will pull in libnl automatically. (I just tested this on my Fedora 16 virtual machine.) It may cause issues when *statically* linking with libpcap, but programs that use autoconf and use "pcap-config --static --libs" to find out what libraries are needed when linking statically with libpcap should work. (Speaking of the .spec file, does it need -fno-strict-aliasing? Tcpdump currently probably does - if somebody has a suggestion as to how to make it not do so when building on machines that do unaligned accesses, without falling back on extracting 2-byte, 4-byte, and 8-byte integral constants one byte at a time in the extract.h macros, it would be appreciated - but does libpcap?)