Bug 765716 - libpcap should be linked with libnl
libpcap should be linked with libnl
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libpcap (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-09 03:27 EST by Guy Harris
Modified: 2014-03-31 15:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-28 20:14:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Guy Harris 2011-12-09 03:27:06 EST
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?)
Comment 1 Michal Sekletar 2012-05-15 09:37:28 EDT
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.
Comment 2 Fedora End Of Life 2013-04-03 15:34:29 EDT
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
Comment 3 Michal Sekletar 2014-03-28 19:40:24 EDT
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.
Comment 4 Guy Harris 2014-03-28 20:29:53 EDT
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.
Comment 5 Account closed by the user 2014-03-29 03:15:44 EDT
You should use libnl3 instead of libnl.
Comment 6 Guy Harris 2014-03-29 03:26:01 EDT
"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.
Comment 7 Account closed by the user 2014-03-31 03:29:41 EDT
(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
Comment 8 Michal Sekletar 2014-03-31 05:18:20 EDT
(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.
Comment 9 Guy Harris 2014-03-31 15:44:31 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.